Skip to main content
Glama
elfa-ai

Elfa MCP

Official
by elfa-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

API key status

api_status
Read-onlyIdempotent

Check Elfa API key tier, credit usage, remaining requests, and reachability. Call this first when requests fail with auth or credit errors.

Instructions

Check the Elfa API key tier, credit usage and remaining requests, and confirm the API is reachable. Free. Call this first when a request fails with an auth or credit error. historyFrom is the earliest time, in unix seconds, the events, market and calls tools read on this plan.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
keyYes
problemYes
reachableYes
historyFromYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.8.0
    • addedOutput schema / properties / historyFrom
      Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
    • changedOutput schema / required
      Previous value: -[
-  "reachable",
-  "key",
-  "problem"
-]New value: +[
+  "reachable",
+  "key",
+  "historyFrom",
+  "problem"
+]
  2. First observedv2.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new context: the call is 'Free' (no credit cost), it is a reachability probe, and it is the first diagnostic to run on auth/credit failures. It doesn't describe latency or failure modes, keeping it below 5.

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?

Three tight sentences, front-loaded with the core purpose, then cost, then the trigger condition. The trailing historyFrom sentence is useful plan context but is the least essential and is slightly ambiguous in a zero-parameter tool.

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?

An output schema exists so return values need not be explained. Given a parameterless, read-only diagnostic, the description covers purpose, cost, trigger, and the plan-scoped data limits an agent needs to interpret the result.

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?

The tool takes zero parameters, so the baseline is 4 and the schema (empty object, 100% coverage) carries the full burden. The mention of historyFrom is not a parameter but a plan-limit detail, which adds context about what the returned tier implies, though it reads slightly as if it were an input.

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 with three named resources: checks API key tier, credit usage/remaining requests, and reachability. This is unmistakably a diagnostics tool and cannot be confused with any sibling such as market, calls, or events.

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?

Gives an explicit trigger: 'Call this first when a request fails with an auth or credit error.' That is a clear usage condition. It lacks any when-not guidance (e.g., don't call it alongside every request), so it falls just short of the top bar.

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

Deploy Server

Other Tools