Commertize Agents MCP Server

Official

by Commertize-Inc

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Compare Commertize offerings side by side

compare_offerings

Read-only

Compare two to five public offerings field by field across asset class, geography, status, sponsor, tokenomics, size, and SPV leverage. See disclosure gaps and agreement.

Instructions

Align two to five public offerings field by field: asset class, geography, status, exemption, sponsor, tokenomics, derived offering size, SPV leverage and sponsor projections. Each row reports how many of the compared offerings disclose the field, whether they agree, and whether only some disclose it. Two nulls are reported as two absences, never as agreement. Ids come from list_offerings or search_offerings. Informational reference data — not an offer, solicitation, or recommendation.

Input Schema

Name	Required	Description	Default
`offering_ids`	Yes	Two to five offering UUIDs. Comparison rows follow this order.

Output Schema

Name	Required	Description
`rows`	Yes
`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.
`not_found`	Yes	Requested ids with no public offering. Present so a comparison of 4 is never silently a comparison of 3.
`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.
`offering_ids`	Yes
`offering_names`	Yes
`differing_fields`	Yes	Fields every offering discloses and on which they differ.
`undisclosed_by_all`	Yes	Fields NO compared offering discloses. The shape of the data gap, stated rather than left as a column of nulls.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 15, 2026

TDQS

A4.3/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 genuinely useful behavioral semantics not in annotations: how each row aggregates disclosure counts, agreement, and partial disclosure, and the notable rule that two nulls are treated as two absences rather than agreement.

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?

Front-loaded with the action and field list, then the row-semantics rule, then the ID source, then the legal disclaimer. It is dense but each sentence earns its place; the disclaimer is slightly tangential but justified for a financial reference tool.

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?

With an output schema present, the description need not explain return values, and it correctly focuses on the aggregation semantics the agent must interpret. It is complete for invocation; only an explicit when-not-to-use note is missing.

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 single parameter is fully documented, so the baseline is 3. The description adds value beyond the schema by naming the upstream tools that supply the UUIDs, which the schema does not state.

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 (align/compare) and resource (two to five public offerings) and enumerates the exact fields compared, so the agent knows precisely what output to expect. It also implicitly distinguishes itself from list_offerings/search_offerings, which it names only as ID sources rather than peers.

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?

Explicitly tells the agent where offering_ids come from (list_offerings or search_offerings), which is the key prerequisite. It does not state when not to use the tool or contrast it with get_offering for single-offering lookups, so it falls just short of full alternative routing.

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

Deploy Server