Skip to main content
Glama
Sign In

Kivel

by io.kivel
OverviewDiscussionsAdmin

resource_request

DestructiveIdempotent

Manage webhook, email, mock API, file, authenticator, vault, test payment and mock MCP resources through HTTP lifecycle routes. Authenticators support create, inspect, list, update (name) and delete only; use them only for accounts your human asked you to create or operate. Use calls for mock history; response or forward with config to configure a webhook (config.reset=true restores defaults); deliveries reads forwarding history. Email supports create, inspect, delete and renew; mail reading stays private.

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": {
      "action": "<action>"
    },
    "name": "resource_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoResource UUID for existing resources.
kindNo
tokenNoAnonymous resource token, when needed.
actionYes
configNo
persistentNo
ttlSecondsNo
visibilityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds useful behavioral context such as config.reset=true restoring defaults and mail reading staying private, but it does not disclose the side effects of delete/clear/pay/complete actions or any permission/auth requirements beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense paragraph that front-loads the broad purpose and then jumps between authenticators, mock/webhook actions, and email. It is not verbose, but the run-on structure makes it harder to map actions and constraints than a more organized presentation would be.

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

Completeness2/5

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

This is a complex generic tool with 8 parameters, multiple enums, a nested config object, destructive annotations, and no output schema. The description covers only a fraction of the kind/action combinations and omits how most parameters affect behavior, leaving the definition incomplete for reliable invocation.

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

Parameters2/5

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

Schema coverage is only 25%, so the description must compensate. It explains some action values (calls, response, forward, deliveries) and config.reset, but leaves kind, persistent, ttlSeconds, visibility, the config object generally, and most action values undocumented in both schema and description.

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?

The description states a specific broad purpose: managing webhook, email, mock API, file, authenticator, vault, test payment and mock MCP resources through HTTP lifecycle routes. It also enumerates some action subsets for authenticators and email. However, it does not clearly distinguish this generic dispatcher from the many resource-specific sibling tools such as create_mock_api or delete_authenticator.

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

Usage Guidelines3/5

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

The description gives some action-specific guidance: authenticators are limited to accounts the human asked for, calls retrieves mock history, response/forward configures a webhook, and deliveries reads forwarding history. It does not state when to use this tool versus the specialized sibling tools, nor does it provide explicit exclusions or prerequisites for most kinds/actions.

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

All Kivel toolsInspect
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