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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds genuine behavioral value beyond that: markup and embedded metadata are stripped, telling the agent what form the returned text takes. Permissions or rate limits are not mentioned, keeping this out of 5 territory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tightly worded sentence with no redundancy; the resource identity is front-loaded and the output-transformation note follows immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one required, fully documented parameter, an output schema present, and annotations covering the safety profile, the description supplies everything an agent needs to call this correctly. Return-value details are rightly left to the output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by stating where the slug originates ('from get_news') and confirming the parameter selects a single article, which aids correct invocation beyond the schema's format example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and scope: 'Full published text of a single Commertize news or commentary article, by slug'. An agent can immediately distinguish this from the list-oriented sibling get_news, which is explicitly cited as the slug's source.

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

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

It gives clear context for use by stating the slug comes 'from get_news', which routes the agent through the correct sibling first. It stops short of explicit when-not guidance (e.g., when to prefer a listing tool for multiple articles), so it is clear but not fully prescriptive.

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

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 context beyond that: the return granularity (headlines and summaries, not full bodies) and the editorial provenance ('Commertize's own editorial view, not independent research'), which signals potential source bias to the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with no filler. Topic scope, return shape/alternative routing, and source caveat are each front-loaded in that order of importance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 no elaboration, and annotations cover the safety profile. Between the topic scope, the headline-vs-full-body distinction, the sibling handoff, and the editorial bias caveat, an agent has everything needed to select and call this tool correctly.

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

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

Schema description coverage is 100% and all three parameters (limit, query, category) are fully documented in the schema, including the local-substring semantics of query. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Published news and market commentary from Commertize') and instantly scopes the subject matter (tokenization, RWAs, digital capital markets, regulation). It also distinguishes itself from the sibling get_article by stating that this returns headlines and summaries only.

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

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

Explicitly routes the agent: 'use get_article for a full body'. That is a clear alternative-with-condition. It does not, however, state when this tool should be preferred over unrelated siblings like list_offerings or search_offerings, nor any exclusion conditions.

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

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.

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.

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.

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.

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.

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.

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

Annotations cover only readOnlyHint and openWorldHint; the description adds substantial behavioral context beyond them — that the endpoint is authenticated, that prior deals, realized returns, AUM, principals and verification status are unavailable, and that absences are stated explicitly rather than omitted. It also discloses the informational, non-solicitation nature of the data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded with the core scope and the key caveat before the ancillary disclaimers. It is dense but each clause carries distinct information; the final sentence is a boilerplate disclaimer that earns slightly less than the rest.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though an output schema exists, the description usefully sets expectations about what the response contains and, unusually, what it deliberately declares absent. Combined with the single-parameter schema, an agent has everything needed to call it correctly and interpret the result.

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

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

Schema description coverage is 100% and the schema already documents both the exact-id and case-insensitive-substring forms, so the description's 'by id or by name substring' is essentially a restatement. It adds no syntax or matching-behavior detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('One sponsor's public record') and enumerates what the record contains (offerings by status, asset class, geography). It clearly distinguishes itself from list_sponsors and get_offering by scoping to a single sponsor and by the explicit 'NOT A TRACK RECORD' framing.

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

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

It gives clear context on the lookup key ('by id or by name substring') and an explicit when-not ('NOT A TRACK RECORD') tied to the authenticated endpoint's limits. It does not, however, route the agent to specific siblings such as list_sponsors or search_offerings when a lookup fails or when multiple sponsors are needed.

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

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.

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.

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.

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.

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.

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.

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 behavior beyond them: it clarifies that only offerings with public listings appear, that target raise is summed only over offerings that disclose one, and that every response names unavailable data fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the returned fields before the caveats, which is the right ordering. It is a dense single block and the final 'not an offer, solicitation, or recommendation' clause is boilerplate, but overall it is efficiently packed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 shape, and it instead supplies the interpretive framing an agent needs: what constitutes a sponsor here, which aggregates are conditional, and which data classes are absent platform-wide.

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

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

The tool takes zero parameters, so the schema carries nothing to misinterpret and the baseline is 4. The description correctly implies there is no filtering input, describing the response scope instead.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Every sponsor with a public offering on Commertize') and enumerates exactly what each row contains (offering count, status/asset-class breakdown, states, summed target raise). An agent can distinguish this list-of-sponsors tool from siblings like get_sponsor and list_offerings without opening the schema.

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

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

Strong scoping about what the dataset covers and explicitly rules out track-record attributes (prior-deal, realized return, AUM, principal). However, it never routes the agent between this and get_sponsor for a single sponsor or list_offerings, so tool-selection guidance is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context by stating the content is static reference text rather than live data, and by summarizing the covered topics, though it does not discuss return format or permissions (the output schema handles returns).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence carries the purpose, the when-to-use instruction, the enumeration of content areas, and the static-vs-live distinction without any wasted clauses. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless documentation tool with annotations covering safety and an output schema covering returns, the description supplies everything an agent needs: what it is, what it contains, and when to read it. No gaps remain.

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

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

With zero parameters, there is no parameter semantics to convey, so the baseline of 4 applies. The description correctly does not attempt to invent parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (curated reference text about Commertize) and enumerates exactly what topics it covers, distinguishing it from the sibling tools that list, get, or search live data. An agent can immediately tell this is background/context material rather than an operational tool.

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

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

It explicitly says an agent 'should read before using the other tools' and contrasts this with 'Static text, not live data', giving clear when-to-use and when-not guidance. The alternative is implicitly all live-data siblings, which is sufficient for a documentation tool.

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

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

Goes well past the readOnlyHint/openWorldHint annotations: it declares the decimal-fraction convention for rates, that undisclosed values never match a range filter and are surfaced in `excluded_not_disclosed` instead of dropped, and that `field_coverage` explains empty results. Sort-last behavior for undisclosed sort fields is also disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose in the first clause, then adds only high-value caveats (rate units, non-disclosure handling, public-only scope). Dense but every sentence carries information; the long opening clause is the only mild readability cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 29-parameter, zero-required screening tool with an output schema, this covers exactly what the schema cannot: unit conventions, filter semantics, and the existence/meaning of `excluded_not_disclosed` and `field_coverage`. An agent has enough to call and interpret it correctly.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds genuinely non-schema semantics: rates are decimal fractions (0.06 = 6%), undisclosed values never match ranges, and sorting works on any numeric field. That materially changes how an agent sets the min/max parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Screen') and resource ('public Commertize offering set') and enumerates the filter families it supports. Reads clearly as a filtered-search tool, distinguishable from list_offerings (plain list) and get_offering (single record) among the siblings.

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

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

Explains the semantics of use ('public data only', 'filters narrow the public set and never widen it') and the informational nature, but never names an alternative or states when NOT to use it (e.g., versus list_offerings or compare_offerings). Usage is implied rather than routed.

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