Yuppsy

property_try_add

Try to fetch property market info of the web and add property to system. If successful, it returns a success response along with the newly created property's ID.

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": {
      "data": "<data>"
    },
    "name": "property_try_add"
  }
}

Input Schema

Name	Required	Description	Default
`data`	Yes	The property info data.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026
- addedInput schema / properties / data / description
```
Added value: +"The property info data."
```
Changed1 schema field changedNov 5, 2026
- addedInput schema / properties / data / required
```
Added value: +[
+  "address"
+]
```

Changed6 schema fields changedNov 5, 2026

addedInput schema / properties / data / properties / address / description

Added value: +"One line address, e.g. 29 Main St Apt 4B, City, State ZIP"

addedInput schema / properties / data / properties / agentExternalId / description

Added value: +"Agent is required when adding a property. If external id is associated with an agent, it will be used. The priority is AgentId over AgentExternalId."

addedInput schema / properties / data / properties / agentId / description

Added value: +"Agent is required when adding a property. This is the agent id of the agent who will be associated with this property. This can be null if the AgentExternalId is provided."

addedInput schema / properties / data / properties / externalId / description
```
Added value: +"Property external id, if any."
```

addedInput schema / properties / data / properties / propertyId / description

Added value: +"The id of the property. Can be ignored if ExternalId is provided."

addedInput schema / properties / data / properties / public / description
```
Added value: +"Set the property public status."
```

AddedOct 31, 2026

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It discloses an external web fetch, a property creation mutation, and a success response containing the new ID, but it omits failure semantics, whether a property can still be created when lookup fails, permissions, duplicate handling, and idempotency.

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 two tightly written sentences with no filler. It front-loads the action and follows with the success return, so every sentence earns its place.

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?

For a mutation tool that also performs an external web lookup, with no annotations and no output schema, the description gives only the success outcome. Missing failure behavior, output details beyond the new ID, and the relationship to property_add leave an agent under-informed.

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

Parameters3/5

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

The nested data parameter has 100% schema description coverage, including address and agent ID priority details. The description adds little beyond calling it property info data, but the schema itself provides strong parameter semantics, so the baseline 3 is appropriate.

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 combined action: fetch property market info from the web and add a property. It broadly distinguishes this from a plain property_add by mentioning web lookup, but it does not explicitly name or contrast the sibling tool.

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

Usage Guidelines2/5

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

Usage is only implied: use this when adding a property while attempting a web market-info lookup. It does not explain when to choose property_try_add versus property_add, what prerequisites apply, or what happens if the web lookup fails.

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

All Yuppsy 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.

Resources

Need Help?