Skip to main content
Glama
Sign In

Kelpo

by app.kelpo
OverviewDiscussionsAdmin

kelpo_request_confirmation

Terms of use only: create a single-use link (valid 15 minutes, bound to this account) for the account holder to accept the terms on kelpo.app, signed in with the same account (a box to tick). Never use it for rights: rights are one yes asked in the conversation with the price, then rights_confirmed=true. Opening the page validates nothing. Poll kelpo_confirmation_status. Allowed even before the terms are accepted. status=not_required means nothing is missing (no link). Arguments: {"path": {"id": ""}, "body": {"items": ["terms"]}}

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": {
      "path": "<path>",
      "body": "<body>"
    },
    "name": "kelpo_request_confirmation"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYes
pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $defs / ConfirmationInput / properties / items / description
      Previous value: -"What to ask: 'terms' (terms of use not yet accepted) and/or 'rights' (references not covered by a rights declaration). Only what is really missing is included."New value: +"['terms'] (terms of use not yet accepted). Rights are never asked by link: one yes in the conversation, then rights_confirmed=true."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare a non-readonly, non-idempotent, non-destructive write; the description supplies the operational facts the agent actually needs: the link is single-use, expires in 15 minutes, is bound to this account, requires the holder to be signed in with the same account, and 'Opening the page validates nothing' (so success cannot be inferred from page load). That last point is exactly the kind of non-obvious behavior 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-loads the core purpose and the rights exclusion before any detail, and the telegraphic style packs a lot of operational fact into a short block. The trailing raw JSON argument dump is slightly awkward and the sentence flow is choppy, but almost nothing is filler.

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?

For a nested-object, non-idempotent mutation with no output schema, it covers the lifecycle (create link, poll status, what status values imply) and the safety caveats thoroughly. The one omission is that it never states that the response carries the link URL the agent must hand to the user, which is the tool's primary payload.

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 schema's path.id is only titled 'Id' with no description, and the description rescues it by showing the literal argument shape and labelling it '<project id>'. It also pins items to ['terms']. However, quote_id and asset_ids are never mentioned in the description, so an agent must fall back to the schema text for those two fields; given the reported 0% coverage signal, that is a real, if minor, gap.

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?

Opens with a specific verb+resource and an explicit scope qualifier: 'Terms of use only: create a single-use link... for the account holder to accept the terms on kelpo.app.' It immediately carves itself away from the rights flow and from the sibling kelpo_confirmation_status (which it tells the agent to poll), so an agent can pick it out of a 48-tool list without opening the 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 both when-to-use ('Allowed even before the terms are accepted', status=not_required means nothing is missing) and an explicit when-not-to-use with the alternative procedure: 'Never use it for rights: rights are one yes asked in the conversation with the price, then rights_confirmed=true.' It also routes the agent to kelpo_confirmation_status for verification rather than to this tool.

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

All Kelpo 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