crowdspace

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

With no annotations provided, the description carries the full burden. It transparently explains that the tool returns news items with specific fields and clarifies the URL behavior for syndicated items. However, it does not disclose details like rate limits, pagination behavior, or data freshness, which would add further transparency.

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 description is concise and well-structured, with two focused sentences. The first sentence defines the output and the second provides usage guidance. Every sentence adds value, and there is no unnecessary repetition or filler.

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?

Given the tool has 7 optional parameters, an output schema, and no required parameters, the description is complete. It covers the tool's purpose, use cases, boundaries, and output format. The output schema handles return value details, so the description does not need to elaborate on that.

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 echoes the filter criteria (category, kind, date range) but does not add significant new meaning beyond what the schema already provides. It does not introduce any parameter-specific clarifications or examples.

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 clearly states the tool's purpose: retrieving recent crowdfunding and P2P lending news with specific fields (headline, summary, date, category, link). It explicitly distinguishes from the sibling tool 'search_platforms' by stating it is a news feed, not a catalogue, and directs the agent to use the sibling for factual platform data.

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?

The description provides explicit guidance on when to use the tool ('what happened recently / any news about X' questions) and when not to use it (to establish facts about a platform). It also mentions citing the URL correctly for syndicated items and points to the alternative tool 'search_platforms' for current data.

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?

Since no annotations are provided, the description bears the full burden. It clearly states the tool returns aggregate figures only, not platform names, and that figures reflect the live catalogue at call time. It does not mention rate limits, auth requirements, or potential performance implications of broad queries, but the core behavioral constraint (no platform names) is well-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?

The description is a tight four sentences with zero redundancy. It front-loads the aggregate-output scope, lists concrete figures, explains filtering, then gives usage and anti-usage guidance. Every sentence 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?

Given 6 optional params, 100% schema coverage, and an output schema that presumably documents return fields, the description is nearly complete. It covers purpose, usage, filtering, and exclusions. Only minor gaps remain: it does not specify whether filters combine as AND or OR, nor the time-to-live of cached data. Still, for a complex analytical tool, this is robust.

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 schema already provides detailed enums, defaults, and per-parameter descriptions. The description adds meaning by explaining the listing parameter's two different filter sets and the effect of omitting filters entirely. A small deduction because it does not further clarify the interaction between multiple filter arrays (e.g., logical AND vs OR).

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 uses a specific verb ('aggregate figures') and resource ('slice of the crowdfunding market'), and clearly distinguishes the tool from siblings by explicitly naming search_platforms as the alternative for platform names. It also lists exact outputs (counts, regulation, returns, investment types, industries), making the purpose unmistakable.

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?

The description explicitly states when to use this tool ('how big / how regulated / what is typical' questions) and when not to use it ('Do NOT use it to name platforms'), directing to search_platforms. It also explains how to slice data (by country, industry, region filters) and that omitting filters gives the whole market.

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?

With no annotations provided, the description fully bears transparency. It discloses the tool reports catalogue data on supervision, clarifies it is not legal advice, and excludes tax or investor-eligibility rules. It does not explicitly state read-only behavior, but the non-destructive nature is implied.

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 description is a single, well-structured paragraph. It front-loads the core purpose, follows with usage guidance, and ends with a disclaimer. Every sentence contributes necessary information without redundancy. Ideal length for an MCP 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?

The tool has two optional parameters and an output schema. The description covers what the tool returns (regime, authorities, licence type, counts), how to use it, and important caveats (not legal advice, length warning). No auth details are needed. The description is self-sufficient given the tool's complexity.

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% with clear parameter descriptions. The description adds value beyond the schema: it explains that omitting the country returns all countries (with a length warning), and gives practical usage guidance. This raises the score above the baseline of 3.

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 clearly states the tool retrieves the regulatory per-country picture including regime, authorities, licence type, and platform counts. It specifies the exact question types to use, and the name 'get_regulatory_map' matches the resource. Siblings are distinct tools, so no confusion.

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?

The description explicitly tells when to use the tool (e.g., 'is crowdfunding regulated in X?') and advises to omit country for all results or name a country to avoid a long answer. It does not explicitly mention when not to use it or compare to siblings, but the siblings are clearly different functions.

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?

With no annotations provided, the description fully discloses key behavioral traits: the tool does not change the website, the report goes to a human review queue, and the tool result communicates this. It does not mention rate limits, authentication requirements, or duplicate handling, but the core non-destructive nature and workflow are transparently described.

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 description is a single paragraph that efficiently covers purpose, usage conditions, behavioral caveats, and parameter tips. Every sentence adds essential information with no redundancy. It is front-loaded with the core purpose and immediately provides actionable guidance.

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?

Given the tool has an output schema and 100% schema coverage, the description does not need to detail return values. It covers purpose, usage, behavior, and parameter hints sufficiently. Minor gaps exist (e.g., no mention of duplicate checks), but for a simple reporting tool the description is largely complete.

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%, establishing a baseline of 3. The description adds value beyond the schema by emphasizing how to fill the 'problem' field (in a sentence) and the 'evidence_url' field (a checkable URL), and implicitly encouraging use of 'suggested_value'. This contextual guidance enhances parameter understanding.

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 clearly states the tool's purpose: reporting inaccuracies in the CrowdSpace catalogue. It provides specific examples (minimum investment, regulator, dead website) and uses a specific verb ('report') on a defined resource. The purpose is distinct from sibling tools (get_industry_news, search_platforms, etc.), which are about retrieving information rather than reporting errors.

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?

The description explicitly states when to use the tool ('when a reader points out an error, or when you can see the catalogue disagrees with a source you have') and what not to do ('do not tell the user the data has been corrected'). It also instructs the agent to include evidence URL for actionability. This provides clear usage boundaries and response guidance.

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?

No annotations are provided, so the description carries the full burden. It clearly states that the tool returns platform names, types, industries, country, min investment, return range, and profile URL, and instructs to link the URL. It also says that fees, descriptions, and terms are deliberately not included. This is good behavioral context, though it could mention pagination or rate limits more explicitly.

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 description is well-structured: begins with the core purpose, lists return fields, gives use cases, and provides clear 'do NOT use' instructions. Every sentence adds value without redundancy. It is front-loaded and concise.

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?

Given the tool's high complexity (23 parameters, filtering, pagination) and that an output schema exists (though not provided here), the description covers the essential behavioral boundaries: what it returns, how to cite, what to avoid, and points to get_market_overview for alternative use cases. It is complete enough for an AI agent to decide when and how to invoke it.

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 schema already thoroughly documents every parameter with descriptions and common values. The description adds general context about what the tool returns and its usage boundary, but does not add specific parameter-level details beyond the schema. Baseline 3 is appropriate.

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 the tool searches the CrowdSpace catalogue of crowdfunding and P2P lending platforms, and lists exactly what is returned per platform. It clearly distinguishes from siblings by mentioning get_market_overview and implicitly from the profile page. The verb 'search' and resource 'platforms' are specific and actionable.

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?

The description explicitly says when to use this tool ('which platforms let me…' questions) and when not to use it (not for a full platform profile, not for market-wide numbers). It provides an alternative tool (get_market_overview) for market-wide aggregates. This is exemplary guidance.

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