fermi

Send feedback to the Fermi team

feedback

Cost: free.

Submit feedback, a feature request, or a bug report to the Fermi team.

An email is sent to the team and a copy is sent to the address you provide.

Args:
    feedback_type: One of "feedback", "feature_request", or "bug".
    message: Your feedback or request (10-5000 characters). Be specific.
    sender_email: Your email address. A confirmation copy is sent here.
    sender_name: Your name (optional).
    api_key: Your Fermi API key (optional). If provided, your account ID
        is attached to the message for context.

Returns:
    Confirmation with status "sent", plus the `billing` block every
    Fermi tool response carries -- `charged_to` is "none" here, because
    sending feedback spends neither quota nor credits.

Raises:
    ToolError: if validation fails or email delivery fails.

Input Schema

Name	Required	Description	Default
`api_key`	No
`message`	Yes
`sender_name`	No
`sender_email`	Yes
`feedback_type`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026
- changedOutput schema / additionalProperties
```
Previous value: -{
-  "type": "string"
-}New value: +true
```
First observedOct 28, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the side effect (an email is sent to the team plus a copy to the sender), the account-ID attachment behavior when api_key is supplied, and the exact ToolError failure modes. It also pre-empts confusion about the billing block by explaining that charged_to is "none" here, which no annotation conveys.

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-loads the cost note and the purpose before the structured Args block, so an agent gets the decision-relevant facts immediately. The Args/Returns/Raises formatting is somewhat verbose and restates parameter names, but each entry adds real constraints rather than padding.

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 five-parameter write-side tool with an output schema, it covers everything needed to call correctly: required vs optional fields, character limits, side effects, error conditions, and confirmation shape. It even explains the billing block, so no follow-up inference is needed.

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

Parameters5/5

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

Schema description coverage is 0%, so the full semantic burden falls on the description, and it delivers: each of the five parameters is explained, including the enum values for feedback_type, the 10-5000 character bound on message (a constraint absent from the schema), and the optionality and effect of sender_name and api_key.

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

Purpose5/5

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

The first line states a specific verb and resource: submit feedback, a feature request, or a bug report to the Fermi team. This is trivially distinguishable from every sibling (buy_credits, estimate, get_estimate, whoami), none of which share the feedback function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It opens with "Cost: free" and clarifies that feedback spends neither quota nor credits, which is exactly the context an agent needs before choosing to call it in a budget-sensitive workflow. There are no competing siblings to route between, so the absence of explicit exclusions is minor, but it never states a when-not-to-use condition.

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?