Skip to main content
Glama
Sign In

Fabrica (Sepolia testnet)

by land.fabrica
OverviewDiscussionsAdmin

Get sign request status

get_sign_request
Read-onlyIdempotent

Get a sign request a prepare tool returned (make_land_offer, list_land_for_sale, accept_land_offer, buy_land, cancel_land_order, borrow_against_land, repay_loan_against_land, transfer_land, update_trust_agreement, update_land_description, update_land_photos, deposit_to_lending_pool, withdraw_from_lending_pool) by its id: pending or completed, with the order hash, transaction hash or loan id once signed. A pending request is also checked against the live order book, the property's loans for a borrow or payoff, the property itself for an owner change, or the pool's log for a deposit or withdrawal. Requests expire 15 minutes after they are prepared. A purchase or payoff paid on the sign page by card, bank transfer or wire shows as payment_clearing, with the payment's stage and expected date, until it lands; such requests are followed for two weeks. Other expired requests are kept a day, then reported as unknown.

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": {
      "id": "<id>"
    },
    "name": "get_sign_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe sign request id (sr_...) a prepare tool returned

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the readOnly/idempotent/openWorld annotations: it discloses that pending requests are re-checked against live sources (order book, loans, property ownership, pool log), that requests expire after 15 minutes, that card/bank/wire purchases surface as payment_clearing and are tracked for two weeks, and that other expired requests persist a day before reporting unknown. These are exactly the timing and lifecycle traits an agent cannot get from annotations.

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?

Purpose and scope are front-loaded and every sentence carries information about statuses, expiry, or polling behavior. The one cost is the 13-item parenthetical tool list, which is dense and could have been summarized as "any prepare tool", making the opening sentence harder to scan.

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?

There is no output schema, so the description must carry return semantics, and it does: pending vs completed, order hash, transaction hash, loan id, payment_clearing with stage and expected date, and the unknown fallback. Combined with the expiry and tracking windows, an agent has everything needed to call this and 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?

Schema coverage is 100% and the schema already documents the sr_... format, so the baseline is 3. The description adds real value by specifying that the id is one returned by a prepare tool and by enumerating which prepare tools produce such ids, which tells the agent where a valid value can come from.

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 ("Get a sign request ... by its id") and immediately scopes the id's provenance to prepare tools such as make_land_offer and buy_land. It also names the possible outcomes (pending or completed) and the payload fields, so an agent can distinguish it from the get_transaction_status / get_adding_status siblings without opening a schema.

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?

Usage is clearly implied and enumerated: this is the follow-up call after any of the 13 listed prepare tools returns a sign request id. It does not explicitly say when NOT to use it, e.g. that a plain on-chain transaction should go to get_transaction_status instead, so routing between the several status tools still requires inference.

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

All Fabrica (Sepolia testnet) 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