Fabrica (Sepolia testnet)

Add a property to Fabrica

add_land

Idempotent

Start adding a property to Fabrica (Sepolia Testnet) from one of: listingUrl, a listing page on another website (the web app reads it: title, price, acres, the seller's description, photos, parcel number, county and state, and names the parcel); parcelNumber with state and county; or address. Finds the parcel and whether it is already on Fabrica. Signed in with the add-property grant, it then creates the property's record as the connected person, held by their linked account (wallet picks one when several are linked), with the listing's description and photos, and returns where it stands: the steps, and the questions the county asks for this property. Next the owner is asked who holds title on the deed and those questions, and answer_adding_questions saves them. Starting the same parcel again returns the existing record. Not signed in, or without the grant, it returns links.addToFabrica, the fabrica.land page that adds the parcel. Nothing is signed, paid or recorded by this tool: the fee approval and the notarized signature happen on fabrica.land.

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": "add_land"
  }
}

Input Schema

Name	Required	Description
`state`	No	Two-letter state, with parcelNumber (and to narrow an address)
`county`	No	County name, with parcelNumber (and to narrow an address)
`wallet`	No	Signed in with several linked accounts: the one that will hold the property. Left out, the only linked account is used.
`address`	No	The property's street address, with city and state
`listingUrl`	No	A listing page on another website (https link). The web app reads it: title, price, acres, the seller's description, photos, parcel number, county and state, and names the parcel.
`parcelNumber`	No	The parcel number (APN) as the county writes it; give state and county with it

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that the tool finds the parcel and checks whether it is already on Fabrica, creates the property record as the connected person, uses a linked wallet when several exist, and returns steps plus county questions. It also explains the unauthenticated fallback and clarifies that no signing, payment, or on-chain recording happens here, which is exactly the behavioral context an agent needs.

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?

The purpose is front-loaded and nearly every sentence adds useful operational context. It is somewhat dense and repeats some listingUrl extraction details already present in the schema, but it remains readable and appropriately detailed for a complex creation workflow.

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?

Given the lack of an output schema, the description does a thorough job covering what is returned (steps and county questions), what happens next, idempotent re-use of the same parcel, authentication requirements, and the unauthenticated fallback. An agent has enough information to invoke it and understand the surrounding workflow.

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%, so individual parameter meanings are already documented. The description still adds value by explaining that the inputs are alternatives: listingUrl alone, parcelNumber with state and county, or address, and by clarifying wallet selection when multiple accounts are linked.

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?

The description opens with a specific verb and resource: 'Start adding a property to Fabrica (Sepolia Testnet)'. It clearly enumerates the three input paths (listingUrl, parcelNumber with state/county, or address) and distinguishes this tool from the later answer_adding_questions step.

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?

It gives clear context for when to use the tool: starting a property addition from one of three input forms, and it routes the agent to answer_adding_questions for the next step. It also explains the not-signed-in fallback, but it does not explicitly name alternative sibling tools such as find_us_parcel or search_land.

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) tools Inspect

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.