Commertize Agents MCP Server

Official

by Commertize-Inc

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

List Commertize marketplace offerings

list_offerings

Read-only

Retrieve public real-world-asset offerings from the Commertize marketplace and filter them by asset class, US state, status, or result limit.

Instructions

List the real-world-asset offerings currently on the Commertize marketplace, with public terms: asset class, location, status, exemption, sponsor, tokenomics, and derived offering size. Public data only; no authentication. Filters are applied to the public set, they do not widen it. Informational reference data — not an offer, solicitation, or recommendation.

Input Schema

Name	Required	Description
`limit`	No	Maximum number of offerings to return. Default: all.
`state`	No	Filter by US state code, e.g. "WA". Case-insensitive.
`status`	No	Filter by listing status. The public set only ever contains these three.
`asset_class`	No	Filter by asset class code, e.g. "MULTIFAMILY", "HOSPITALITY", "OFFICE". Case-insensitive.

Output Schema

Name	Required	Description
`as_of`	Yes	ISO-8601 timestamp of when the underlying data was fetched from the API — not when this call was made. Older than a few seconds means it was served from cache.
`cache`	Yes	Cache metadata for this response.
`count`	Yes	Number of offerings returned after filtering.
`error`	Yes	Null on success. Populated when the call failed.
`firewall`	Yes	Which offerings this server may publish is decided by the Commertize backend, not here. This states the authority, when it was read, and how much it withheld.
`offerings`	Yes
`disclaimer`	Yes	Standing disclaimer. Carry it into anything you report to a user.
`source_url`	Yes	The upstream public API URL this response was derived from.
`total_available`	Yes	Number of offerings in the set this server may publish, before the caller's own filters. NOT the size of the marketplace — offerings outside the Rule 506(c) set are withheld and are not counted here.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 15, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real value on top by disclosing the no-auth public scope, the constraining (non-widening) filter behavior, and that offering size is a derived field. It stops short of describing pagination or result limits, which is the only remaining behavioral gap.

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?

Three tightly packed sentences that front-load the resource, then the access model, then the filter semantics. The closing disclaimer about informational reference data earns its place in a marketplace context and nothing is redundant.

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?

With an output schema present, the description needn't explain return values, and it covers the remaining essentials: scope of the dataset, authentication model, filter semantics, and legal framing. An agent has everything required to invoke it correctly.

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?

Schema description coverage is 100% and every parameter, including the status enum, is documented in the schema, so the baseline is 3. The description's 'filters are applied to the public set, they do not widen it' adds a semantic constraint on filter behavior, but it does not explain any individual parameter's syntax or defaults.

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 names a specific verb and resource ('List the real-world-asset offerings currently on the Commertize marketplace') and enumerates the public terms returned, so the agent knows exactly what this tool fetches without opening the schema. It does not explicitly differentiate itself from the sibling search_offerings or compare_offerings, leaving the agent to infer the distinction.

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 operating context: public data only, no authentication required, and filters narrow rather than widen the result set. However, it never states when to choose this tool over search_offerings or get_offering, so the routing guidance is contextual rather than explicit.

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

Deploy Server