Commertize Agents MCP Server

Official

by Commertize-Inc

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Get one Commertize offering

get_offering

Read-only

Retrieve full public details for one offering by its UUID, including tokenomics and any sponsor-provided SPV leverage disclosure. Use the ID returned by listing offerings; informational reference.

Instructions

Full PUBLIC detail for a single offering by id, including tokenomics and the SPV leverage disclosure where the sponsor has provided one. The complete listing record (documents, sponsor diligence, street address, funding progress) is authenticated and is NOT available through this server. Informational reference data — not an offer, solicitation, or recommendation.

Input Schema

Name	Required	Description	Default
`offering_id`	Yes	Offering UUID, as returned by list_offerings.

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.
`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.
`offering`	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.
`public_fields_only`	Yes	Always true. Assembled from the public listing endpoint; authenticated detail fields are absent, not null-because-undisclosed.

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 only declare readOnlyHint and openWorldHint, so the description carries the rest and does well: it distinguishes public reference data from authenticated diligence data, notes the SPV disclosure is conditional on sponsor provision, and adds a legal disclaimer that matters for downstream reporting. It stops short of stating error behavior for a missing or invalid id.

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?

Three front-loaded sentences that lead with what is returned before qualifying what is not. The closing disclaimer is boilerplate but defensible for a financial-reference tool; nothing is redundant.

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?

An output schema exists, so return values need not be described, and the description still covers scope, exclusions, and data provenance. What is missing is only peripheral: behavior on a nonexistent id and whether results are cached or rate-limited.

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 the single parameter is documented there as a UUID 'as returned by list_offerings'. The description only echoes 'by id', adding no format or edge-case detail beyond the schema, so the baseline 3 applies.

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 ('Full PUBLIC detail for a single offering by id') and enumerates the payload scope (tokenomics, SPV leverage disclosure). It also explicitly rules out the authenticated listing record, which cleanly separates it from list_offerings and the full-record siblings an agent might otherwise expect.

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?

Clear context for use: fetch one offering when you already have its id. The negative scoping ('the complete listing record ... is NOT available through this server') tells the agent when this tool will not satisfy a need, but it never names an alternative tool or endpoint to use instead.

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

Deploy Server