Skip to main content
Glama

start_credit_ladder

[WRITE] Open the ladder and request the $10 starter limit.

Grants $10 only when the bureau counts a qualifying allowlisted attestation against the wallet; otherwise returns no_qualifying_attestation with the counts, and the agent should earn attested work first at /api/agentworld/slrb/attest/work. One default later resets the limit to $0 and the ladder cannot be reopened.

Input Schema

NameRequiredDescriptionDefault
walletYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it marks the operation as a write, explains the conditional grant, describes the no_qualifying_attestation failure response, and warns that one default resets the limit to $0 and makes the ladder unreopenable.

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?

The description is front-loaded with a clear [WRITE] marker, followed by the grant condition, failure behavior, and irreversible side effect. Every sentence provides operationally relevant information with no 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?

The description adequately covers the write action, precondition, failure state, and irreversibility, and the existence of an output schema means return values do not need full explanation. The main remaining gap is wallet parameter semantics, which are not clarified beyond the bare name.

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?

The schema has 0% description coverage and the description only says the attestation is counted 'against the wallet.' It does not explain the expected wallet format, network, address constraints, or any other meaningful semantics beyond the parameter name itself.

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 write action: opening the credit ladder and requesting the $10 starter limit. It is clearer than the name alone, but it does not explicitly name or distinguish itself from related siblings such as get_credit_ladder or record_credit_ladder_repayment.

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?

It gives explicit conditions for use: the $10 grant only happens when a qualifying allowlisted attestation is counted. It also gives the failure path and next action, telling the agent to earn attested work first at the provided endpoint when no_qualifying_attestation is returned.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources