Skip to main content
Glama
Sign In
Bevel MCP

Bevel MCP

by JoshPopov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Bevel auth status

bevel_auth_status
Read-only

Checks whether a Bevel API token is configured, decodes its non-secret JWT claims locally, and optionally verifies the token with one tiny Bevel request without returning it.

Instructions

Reports whether a Bevel API token is configured and decodes its non-secret JWT claims locally (account, issued/expiry times, lifetime). With checkApi, also makes one tiny request to confirm Bevel accepts it. Never returns the token.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "bevel_auth_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
checkApiNoAlso confirm with Bevel that the token works (one small request).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Adds meaningful behavior beyond the annotations: it declares that claim decoding happens 'locally', that the network request occurs only under checkApi, and that it 'Never returns the token'. This refines the openWorldHint into a conditional network call and gives the agent a secrecy guarantee it could not infer from readOnlyHint alone.

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?

Three short sentences, front-loaded with the primary purpose followed by the opt-in behavior and the safety guarantee. No filler and nothing buried.

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

Completeness4/5

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

There is no output schema, so the description carries the burden of describing returns, and it does — account, issued/expiry times, lifetime, plus an explicit statement that the token itself is not returned. A single-parameter, no-output tool is well covered; only error or failure-shape behavior is unaddressed.

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% and the single checkApi parameter is already documented as 'one small request'. The description's 'makes one tiny request to confirm Bevel accepts it' largely restates that, adding only marginal emphasis on cost. Baseline 3 is appropriate since the schema does the work.

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 ('Reports whether a Bevel API token is configured') plus the secondary capability of decoding JWT claims. The mention that checkApi triggers 'one tiny request' distinguishes the two modes of operation clearly, and none of the sibling tools overlap with auth status.

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?

The description makes the conditional behavior explicit: local decoding by default, and network verification only 'With checkApi'. That tells the agent when to reach for the optional parameter. It doesn't discuss failure modes or when to prefer this over other diagnostics, but the usage context is clear enough.

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