Read-only agent radar, weekly editions, sourced guides, scenario choices and revision sync.
Scored across 11 tools
Most tools have distinct targets (get_item by ID, get_changes stream, get_sources metadata, get_workflows procedures, search). However, get_latest, get_daily and get_observations all return recent published content and could be confused without careful reading, though the descriptions do clarify the distinction.
All 11 tools use a consistent botclaw_ prefix with snake_case verb-based names (get_*, search, choose, compare). The verb_noun convention is predictable throughout with no mixing of styles.
11 tools is well-scoped for a read-only content/observation server, covering catalog, retrieval, search, sync and decision-support without redundancy.
The surface covers the full read lifecycle: catalog enumeration, single-item retrieval, paginated listings, incremental change sync, search, source metadata, workflows and comparison/selection helpers. Minor gaps exist (no dedicated category/product detail fetch), but these are workable via get_catalog IDs and existing filters.
Apply deterministic task, hosting, platform, budget and access gates to published dossiers. Each candidate has sourced reasons, explicit unknowns and hosting conflicts. No performance scores, account-access guarantee, inference, purchase or setup action. no-new-subscription does not establish free inference.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | collect | |
| access | No | any | |
| budget | No | flexible | |
| hosting | No | any | |
| language | No | en | |
| platform | No | any |
| Name | Required | Description |
|---|---|---|
| _trust | Yes | |
| inputs | Yes | |
| choices | Yes | |
| language | Yes | |
| limitations | Yes | |
| rulesVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds useful behavioral limits: deterministic gating, sourced reasons, explicit unknowns, hosting conflicts, no performance scores, no account-access guarantee, no inference/purchase/setup action, and a clarification about no-new-subscription.
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 four short sentences and front-loads the core operation. The final sentence about no-new-subscription is terse but purposeful. There is little wasted wording, though the list of exclusions could be integrated more smoothly.
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 and rich annotations, return values and safety are already covered. The description adds scope and behavioral limits, but given six parameters with 0% schema description coverage, it is not complete enough for an agent to confidently choose enum values or know when to prefer this tool over siblings.
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 0%, so the description must carry parameter meaning. It names five of the six parameters as gates but omits language and does not explain enum values or what each gate does operationally. The budget clarification is slightly helpful but far from sufficient for six undocumented enum 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?
The description states a specific operation: applying deterministic task, hosting, platform, budget, and access gates to published dossiers. This is clearer than a tautology and distinguishes the tool from sibling retrieval/comparison tools. It does not explicitly say what the output is, but the output schema covers that.
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 does not state when to use this tool versus alternatives such as botclaw_compare or botclaw_search. It lists exclusions like no performance scores or purchase action, which implies some boundaries, but gives no explicit routing or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare source-backed capabilities and explicit unknowns for the seven products. Filters can shortlist documented self-managed options. This is official documentation, not a tested product ranking or current account-access guarantee.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | en | |
| products | No | ||
| selfHosted | No |
| Name | Required | Description |
|---|---|---|
| _trust | Yes | |
| evidence | Yes | |
| language | Yes | |
| profiles | Yes | |
| reviewedAt | Yes | |
| limitations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful provenance context: this is official documentation, not a tested ranking or an account-access guarantee. That framing materially affects how an agent should interpret and present results.
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, front-loaded with the core action and scope before the filter hint and the caveat. Every sentence carries weight; the sole weakness is that the caveat could be slightly more compact.
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. For a read-only, zero-required-parameter comparison tool, the description covers action, scope, filter role, and provenance caveats. The only gap is the undocumented language parameter.
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 0%, so the description must compensate. It hints at the filter semantics ('shortlist documented self-managed options' maps to selfHosted, 'the seven products' maps to products) but never explains the language parameter or how product selection interacts with the comparison. Partial compensation only.
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 ('Compare') and resource ('source-backed capabilities and explicit unknowns for the seven products'), which is easily distinguished from the get_*/search siblings. It does not, however, explicitly name a sibling or boundary case to differentiate against. Clear but no sibling differentiation.
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?
'Filters can shortlist documented self-managed options' implies when the tool is useful (narrowing a comparison), but there is no explicit when-to-use vs. when-not, and no alternative tool is named. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the seven tracked products, category and content-type IDs, and the public MCP's paging and language options. Use these IDs in other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | en |
| Name | Required | Description |
|---|---|---|
| _trust | Yes | |
| maxPage | Yes | |
| language | Yes | |
| pageSize | Yes | |
| products | Yes | |
| timeZone | Yes | |
| languages | Yes | |
| categories | Yes | |
| contentTypes | Yes | |
| defaultLanguage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safe-read profile is fully covered structurally. The description adds that the response is a static catalog of IDs and config options, but says nothing extra about caching, freshness, or limits beyond the annotations.
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?
Two short sentences, zero padding, with the returned contents front-loaded and the follow-up use case second. Every clause 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?
An output schema exists, so the description need not describe return values, and it correctly summarizes the catalog's contents and downstream use. Adequate for a zero-required-param lookup tool, with only minor gaps around the language parameter's effect.
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 0% and the single 'language' param (enum en/zh, default en) has no schema description. The phrase 'language options' hints that the param localizes the catalog output, adding some meaning, but it does not spell out the en/zh values or the default.
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 (List) and enumerates the concrete contents: seven tracked products, category/content-type IDs, and paging/language options. It is clearly distinguishable from siblings like botclaw_get_item or botclaw_search, though it never names them.
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?
'Use these IDs in other tools' gives a clear workflow context: this is a bootstrap/reference call whose output feeds other tools. There are no exclusions or explicit when-not conditions, but the intended moment of use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a sequence-ordered change stream after a decimal cursor. Start at 0, persist nextCursor only after applying the page, and continue while hasMore. Upserts contain the current published projection; withdrawn events contain only ID/revision/date, item=null. Remove withdrawn records locally. Replaying a page is safe. This is not a historical full-text archive.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | 0 | |
| language | No | en |
| Name | Required | Description |
|---|---|---|
| _trust | Yes | |
| cursor | Yes | |
| changes | Yes | |
| hasMore | Yes | |
| nextCursor | Yes | |
| highWatermark | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantive behavior: upserts carry the current published projection, withdrawn events carry only ID/revision/date with item=null, and pages are replay-safe. It does not state rate limits, ordering guarantees across concurrent writers, or token expiry, so it stops short of a 5.
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?
Five short sentences, no preamble, front-loaded with the core operation and followed by the paging protocol and event semantics. Every sentence carries distinct information.
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 shapes needn't be fully restated, and the description still characterizes the two event types usefully. The remaining gap is documentation of limit and language behavior, which an agent must infer from the schema alone.
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 0%, so the description must compensate. It explains cursor semantics well (decimal, start at 0, chained via nextCursor) and implies page sizing, but says nothing about the limit bounds/default or the language enum, leaving those purely to the bare schema types.
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 precise verb and resource ('Read a sequence-ordered change stream after a decimal cursor') and explicitly bounds scope with 'This is not a historical full-text archive,' which separates it from archival/search siblings like botclaw_search or botclaw_get_item.
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?
Gives explicit operating procedure: start at 0, persist nextCursor only after applying the page, continue while hasMore, remove withdrawn records locally, and that replaying a page is safe. It also states what the tool is not for, which is genuine when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read public items dated on a real YYYY-MM-DD calendar day in Asia/Shanghai. Omit date for today. This is a date index, not an AI-generated daily report. reviewedAt is a source-review date, not a publication date. Returns 20 items per page.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| page | No | ||
| product | No | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| date | No | |
| kind | No | |
| page | Yes | |
| items | Yes | |
| query | No | |
| total | Yes | |
| _trust | Yes | |
| hasMore | Yes | |
| language | Yes | |
| pageSize | Yes | |
| timeZone | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the timezone (Asia/Shanghai), that reviewedAt is a source-review date not a publication date, and the pagination size (20 items per page). The pagination and date field semantics are valuable additions for correctly interpreting results.
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 four efficient sentences, front-loaded with the core purpose and immediately covering the date format, default behavior, important semantic distinction, and pagination. 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?
The description covers the date semantics, timezone, default behavior, pagination, and clarifies the meaning of reviewedAt. Since an output schema exists, return value details are not needed. It omits guidance on the 'product' and 'language' parameters, which an agent might need to use correctly, but overall it is substantially complete for a read-only index tool.
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 0%, so the description must compensate for parameter documentation. The description explains the 'date' parameter ('YYYY-MM-DD calendar day') and the default behavior ('Omit date for today'), but provides no guidance on the 'product', 'language', or 'page' parameters beyond what the schema's enum/default values already imply. With 4 parameters and no schema-level documentation, the description partially compensates but leaves significant gaps.
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 verb and resource: 'Read public items dated on a real YYYY-MM-DD calendar day in Asia/Shanghai.' It also disambiguates from botclaw_get_latest implicitly through 'date index, not an AI-generated daily report' and defines scope well. It doesn't explicitly name siblings like botclaw_get_latest or botclaw_search, so it falls short of a 5.
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 says 'Omit date for today,' giving a clear default and usage context. However, it doesn't explain when to use this versus botclaw_get_latest or botclaw_search, so sibling selection remains partially unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one published record by stable ID, with body, applicable conditions, evidence type, revision and canonical citation URL. Missing or withdrawn records return item=null. Original-source excerpts are not independent execution evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| item | Yes | |
| _trust | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds non-obvious behavior: missing or withdrawn records return item=null, and original-source excerpts are not independent execution evidence. This usefully supplements the annotations.
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 short sentences with zero waste, front-loaded with purpose and returned fields; the null behavior and evidence caveat follow in tightly scoped statements.
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 read-by-ID tool with full annotations and an output schema, the description covers the essential contract. The omitted language parameter is a minor gap, but the core behavior and null case are addressed.
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 0%, so the description must compensate. It only hints that id is a 'stable ID' and says nothing about the language enum or its default, leaving one of two parameters entirely undocumented.
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 ('Read one published record by stable ID') and lists the returned fields, which clearly distinguishes it from siblings like get_latest or search. An agent can tell what the tool does 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?
Implies usage when a stable ID is known ('by stable ID') but provides no explicit when-to-use, when-not, or alternatives among the many sibling tools. The context is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the latest dated agent news, newest first. Defaults to news; choose content_type guide, experience or review for other reading. Filters are listed by botclaw_get_catalog. Results have 20 items per page; use hasMore and page to continue.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| product | No | ||
| category | No | ||
| language | No | en | |
| selected | No | ||
| content_type | No | news |
| Name | Required | Description |
|---|---|---|
| date | No | |
| kind | No | |
| page | Yes | |
| items | Yes | |
| query | No | |
| total | Yes | |
| _trust | Yes | |
| hasMore | Yes | |
| language | Yes | |
| pageSize | Yes | |
| timeZone | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful pagination behavior (20 items per page, hasMore/page continuation) and newest-first ordering, going beyond the structured safety hints.
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 sentences are front-loaded with purpose and pagination mechanics, with no filler. The sentence about filters being listed by botclaw_get_catalog is slightly indirect but still earns its place by pointing to discovery.
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, return values need not be explained. However, for a six-parameter tool with 0% schema coverage, the description leaves several filter parameters opaque, though it does direct the agent to botclaw_get_catalog for their values.
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 0%, so the description must compensate. It explains content_type (default news and alternatives) and page continuation, but leaves product, category, language, and selected unexplained, failing to cover most of the six 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 and resource: 'Read the latest dated agent news, newest first,' making the scope clear. It does not explicitly differentiate itself from siblings like botclaw_get_daily or botclaw_search, but the 'latest' and ordering cue are reasonably distinct.
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?
Gives implied usage guidance by naming content_type alternatives (guide, experience, review) and pointing to botclaw_get_catalog for filters. However, it does not state when to prefer this tool over siblings such as botclaw_search or botclaw_get_daily.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read published bilingual version radar, weekly editions, question guides or product dossiers. Includes full bodies, source dates, review dates and weekly coverage cutoff. Editorial interpretation is not product execution. Use product to include records discussing that product, including multi-product guides.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| page | No | ||
| product | No | ||
| section | No | radar | |
| language | No | en |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| items | Yes | |
| total | Yes | |
| _trust | Yes | |
| hasMore | Yes | |
| section | Yes | |
| language | Yes | |
| pageSize | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful content scope (published bilingual, full bodies, source/review dates, weekly cutoff) and clarifies that editorial interpretation is not product execution, though it omits auth/rate-limit/pagination behavior.
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?
Four sentences, front-loaded with the core read action, and no sentence is pure filler. The wording is a bit dense ('bilingual version radar'), but it remains appropriately sized.
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 five-parameter tool with no required parameters and 0% schema description coverage, the description leaves q, page, language defaults, and section mapping largely unexplained. The output schema and annotations cover returns and safety, but invocation details are incomplete.
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 0%, so the description must carry parameter meaning. It explains only product (include records discussing a product, including multi-product guides) and vaguely hints at section/language via content types and 'bilingual'; q and page are unmentioned.
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 clear read verb and enumerates the content types returned (radar, weekly editions, question guides, product dossiers), so the resource is identifiable. It does not distinguish this tool from siblings like botclaw_search or botclaw_get_daily, and the phrase 'bilingual version radar' is slightly awkward.
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?
Only guidance is 'Use product to include records discussing that product, including multi-product guides,' which is a parameter instruction, not a when-to-use statement. It does not say when to choose this over search, get_latest, or get_daily.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public source URLs, source origin (official or independent), collection state, last successful collection, and item counts. Manual sources are editorially reviewed; they are not automatic collectors.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| _trust | Yes | |
| counts | Yes | |
| sources | Yes | |
| language | Yes | |
| automaticSummaries | Yes | |
| automaticCollection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds domain-level behavior by distinguishing official/independent origins and manual versus automatic collectors, but says nothing about pagination, rate limits, or permission requirements.
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?
Two tight sentences with the primary purpose front-loaded and no filler. The second sentence is slightly tangential to the listing action but still earns its place by clarifying dataset provenance.
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 the description arguably over-explains return fields while omitting usage guidance and any explanation of its two filter parameters. For a simple read-only list tool this is adequate but leaves real gaps around filtering.
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 0% and both parameters (product, language) are undocumented enums in the description. The description nowhere explains that results can be scoped by product or language, or what the enum values mean, so it fails to compensate for the coverage gap.
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 ('List') and resource ('public source URLs') and enumerates the fields surfaced (origin, collection state, last successful collection, item counts), so an agent knows exactly what it returns. It does not, however, contrast itself with siblings like botclaw_get_catalog or botclaw_get_item, which also deal with source-level metadata.
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?
There is no explicit guidance on when to call this versus alternatives, nor any prerequisite or exclusion. The only contextual note ('Manual sources are editorially reviewed; they are not automatic collectors') describes data semantics, not usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find owned, reproducible workflow procedures. Each list entry has a stable ID; call get_item for steps, pinned versions and verification limits. The RSS example and OpenClaw staging-backup trial have execution evidence; memory behavior and upgrade regressions remain untested. Does not run workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| page | No | ||
| product | No | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| date | No | |
| kind | No | |
| page | Yes | |
| items | Yes | |
| query | No | |
| total | Yes | |
| _trust | Yes | |
| hasMore | Yes | |
| language | Yes | |
| pageSize | Yes | |
| timeZone | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description reinforces with 'Does not run workflows.' It adds genuinely new context by disclosing which entries carry execution evidence (RSS example, OpenClaw staging-backup) and what remains untested (memory behavior, upgrade regressions) — useful trust signals not available elsewhere.
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?
Four short sentences, front-loaded with purpose then routing then evidence caveats. The evidence sentence is longer than needed but every clause maps to real behavior; little waste.
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 needn't be described, and purpose/routing/evidence are covered well. However, with 0% parameter description coverage the four filters go entirely unexplained, which is a real gap for an agent choosing query arguments.
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 0% across four parameters, yet the description never mentions the q, page, product, or language filters or what they constrain. The only hint is that list entries have a stable ID, which doesn't explain how to page, filter by product, or set language.
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: 'Find owned, reproducible workflow procedures,' and distinguishes the detail path by naming get_item for steps and versions. Clearly not the same as the search/catalog siblings, though it doesn't contrast against all of them.
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 agents to get_item for steps, pinned versions and verification limits, and closes with 'Does not run workflows' to exclude execution. It stops short of saying when to prefer this over botclaw_search or botclaw_get_catalog, so no full when/when-not matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published titles, summaries and owned workflow text using bounded bilingual keyword aliases (1–80 characters). Product, content type and category filters apply. Returns up to 20 records per page, not a generated answer or live-internet search. Use get_item to inspect conditions, evidence and citation URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| page | No | ||
| product | No | ||
| category | No | ||
| language | No | en | |
| selected | No | ||
| content_type | No |
| Name | Required | Description |
|---|---|---|
| date | No | |
| kind | No | |
| page | Yes | |
| items | Yes | |
| query | No | |
| total | Yes | |
| _trust | Yes | |
| hasMore | Yes | |
| language | Yes | |
| pageSize | Yes | |
| timeZone | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the bar is lower; the description adds real value with the 20-records-per-page cap, the bounded query length, and the explicit statement that results are records rather than generated prose. It still omits pagination exhaustion behavior and total-count semantics.
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; scope and output nature are front-loaded before the routing hint. The '(1–80 characters)' parenthetical is mildly redundant with the schema's maxLength but earns its place by describing the query's alias nature.
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, return-value detail is unnecessary, and the description still communicates page size and result nature. For a 7-parameter tool with 0% schema coverage, the enum-bearing parameters (language, selected, product) remain the only meaningful gap.
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 0%, so the description must carry parameter meaning. It partially does: it characterizes q (bilingual keyword aliases, bounded length), notes that product/content_type/category filters apply, and implies page size, but leaves language, selected, and the enum values themselves unexplained.
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 (search) over named resources (published titles, summaries, owned workflow text) and scopes it with a negative ('not a generated answer or live-internet search'). This lets an agent distinguish it from catch-all search siblings, though it does not differentiate it from get_catalog/get_workflows by name.
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 names the follow-up alternative ('Use get_item to inspect conditions, evidence and citation URLs') and rules out uses (generated answers, live internet). It gives clear context and one alternative, but does not say when to prefer this over other retrieval siblings like get_latest or get_workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
botclaw_get_sources1 field changedOutput schema / properties / sources / items / properties / messageAdded value: +{
+ "type": "string"
+}botclaw_choosebotclaw_get_changes1 field changedOutput schema / properties / changes / items / properties / item / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "applicability": {
- "additionalProperties": false,
- "properties": {
- "platforms": {
- "items": {
- "type": "string"
- },
- "maxItems": 20,
- "type": "array"
- },
- "requirements": {
- "items": {
- "type": "string"
- },
- "maxItems": 30,
- "type": "array"
- },
- "version": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "version",
- "platforms",
- "requirements"
- ],
- "type": "object"
- },
- "body": {
- "anyOf": [
- {
- "additionalProperties": false,
- "properties": {
- "introduction": {
- "maxLength": 20000,
- "type": "string"
- },
- "sections": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "code": {
- "maxLength": 20000,
- "type": "string"
- },
- "heading": {
- "maxLength": 500,
- "type": "string"
- },
- "paragraphs": {
- "items": {
- "maxLength": 20000,
- "type": "string"
- },
- "maxItems": 50,
- "type": "array"
- },
- "steps": {
- "items": {
- "maxLength": 5000,
- "type": "string"
- },
- "maxItems": 50,
- "type": "array"
- }
- },
- "required": [
- "heading",
- "paragraphs"
- ],
- "type": "object"
- },
- "maxItems": 30,
- "type": "array"
- }
- },
- "required": [
- "introduction",
- "sections"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "canonicalUrl": {
- "format": "uri",
- "type": "string"
- },
- "category": {
- "type": "string"
- },
- "collectedAt": {
- "type": "string"
- },
- "contentType": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "indexable": {
- "type": "boolean"
- },
- "language": {
- "enum": [
- "en",
- "zh"
- ],
- "type": "string"
- },
- "product": {
- "type": "string"
- },
- "review": {
- "additionalProperties": false,
- "properties": {
- "pendingChanges": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "policyDays": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "state": {
- "enum": [
- "current",
- "due",
- "pending",
- "not_reviewed"
- ],
- "type": "string"
- }
- },
- "required": [
- "state",
- "pendingChanges",
- "policyDays"
- ],
- "type": "object"
- },
- "reviewedAt": {
- "type": [
- "string",
- "null"
- ]
- },
- "revision": {
- "maximum": 9007199254740991,
- "minimum": 1,
- "type": "integer"
- },
- "source": {
- "additionalProperties": false,
- "properties": {
- "id": {
- "type": "string"
- },
- "name": {
- "type": "string"
- },
- "origin": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "name",
- "origin"
- ],
- "type": "object"
- },
- "sourcePublishedAt": {
- "type": [
- "string",
- "null"
- ]
- },
- "sourceUrls": {
- "items": {
- "format": "uri",
- "type": "string"
- },
- "type": "array"
- },
- "summary": {
- "type": "string"
- },
- "summaryMethod": {
- "type": "string"
- },
- "supersededBy": {
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": "string"
- },
- "updatedAt": {
- "type": "string"
- },
- "verification": {
- "additionalProperties": false,
- "properties": {
- "checkedAt": {
- "type": [
- "string",
- "null"
- ]
- },
- "kind": {
- "enum": [
- "official_documentation",
- "independent_report",
- "software_execution",
- "source_excerpt"
- ],
- "type": "string"
- },
- "limitations": {
- "items": {
- "type": "string"
- },
- "maxItems": 30,
- "type": "array"
- },
- "urls": {
- "items": {
- "format": "uri",
- "type": "string"
- },
- "maxItems": 30,
- "type": "array"
- }
- },
- "required": [
- "kind",
- "checkedAt",
- "urls",
- "limitations"
- ],
- "type": "object"
- }
- },
- "required": [
- "id",
- "product",
- "language",
- "title",
- "summary",
- "contentType",
- "category",
- "revision",
- "canonicalUrl",
- "sourceUrls",
- "sourcePublishedAt",
- "reviewedAt",
- "collectedAt",
- "updatedAt",
- "source",
- "summaryMethod",
- "applicability",
- "verification",
- "body",
- "indexable",
- "supersededBy",
- "review"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "applicability": {
+ "additionalProperties": false,
+ "properties": {
+ "platforms": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "type": "array"
+ },
+ "requirements": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "version",
+ "platforms",
+ "requirements"
+ ],
+ "type": "object"
+ },
+ "body": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "introduction": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "sections": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "heading": {
+ "maxLength": 500,
+ "type": "string"
+ },
+ "paragraphs": {
+ "items": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "maxItems": 50,
+ "type": "array"
+ },
+ "steps": {
+ "items": {
+ "maxLength": 5000,
+ "type": "string"
+ },
+ "maxItems": 50,
+ "type": "array"
+ }
+ },
+ "required": [
+ "heading",
+ "paragraphs"
+ ],
+ "type": "object"
+ },
+ "maxItems": 30,
+ "type": "array"
+ }
+ },
+ "required": [
+ "introduction",
+ "sections"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "canonicalUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "collectedAt": {
+ "type": "string"
+ },
+ "contentType": {
+ "type": "string"
+ },
+ "editorial": {
+ "additionalProperties": false,
+ "properties": {
+ "period": {
+ "additionalProperties": false,
+ "properties": {
+ "cutoffAt": {
+ "type": "string"
+ },
+ "end": {
+ "type": "string"
+ },
+ "start": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "start",
+ "end",
+ "cutoffAt"
+ ],
+ "type": "object"
+ },
+ "productIds": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 7,
+ "type": "array"
+ },
+ "relatedIds": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ "section": {
+ "enum": [
+ "radar",
+ "weekly",
+ "topic",
+ "profile"
+ ],
+ "type": "string"
+ },
+ "sourceDate": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "section",
+ "productIds",
+ "relatedIds",
+ "sourceDate",
+ "version"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "indexable": {
+ "type": "boolean"
+ },
+ "language": {
+ "enum": [
+ "en",
+ "zh"
+ ],
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "review": {
+ "additionalProperties": false,
+ "properties": {
+ "pendingChanges": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "policyDays": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "state": {
+ "enum": [
+ "current",
+ "due",
+ "pending",
+ "not_reviewed"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "state",
+ "pendingChanges",
+ "policyDays"
+ ],
+ "type": "object"
+ },
+ "reviewedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "revision": {
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "source": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "origin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "origin"
+ ],
+ "type": "object"
+ },
+ "sourcePublishedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sourceUrls": {
+ "items": {
+ "format": "uri",
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "summaryMethod": {
+ "type": "string"
+ },
+ "supersededBy": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": "string"
+ },
+ "updatedAt": {
+ "type": "string"
+ },
+ "verification": {
+ "additionalProperties": false,
+ "properties": {
+ "checkedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "kind": {
+ "enum": [
+ "official_documentation",
+ "independent_report",
+ "software_execution",
+ "source_excerpt"
+ ],
+ "type": "string"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ "urls": {
+ "items": {
+ "format": "uri",
+ "type": "string"
+ },
+ "maxItems": 30,
+ "type": "array"
+ }
+ },
+ "required": [
+ "kind",
+ "checkedAt",
+ "urls",
+ "limitations"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "product",
+ "language",
+ "title",
+ "summary",
+ "contentType",
+ "category",
+ "revision",
+ "canonicalUrl",
+ "sourceUrls",
+ "sourcePublishedAt",
+ "reviewedAt",
+ "collectedAt",
+ "updatedAt",
+ "source",
+ "summaryMethod",
+ "applicability",
+ "verification",
+ "body",
+ "indexable",
+ "supersededBy",
+ "review"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]botclaw_get_item1 field changedOutput schema / properties / item / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "applicability": {
- "additionalProperties": false,
- "properties": {
- "platforms": {
- "items": {
- "type": "string"
- },
- "maxItems": 20,
- "type": "array"
- },
- "requirements": {
- "items": {
- "type": "string"
- },
- "maxItems": 30,
- "type": "array"
- },
- "version": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "version",
- "platforms",
- "requirements"
- ],
- "type": "object"
- },
- "body": {
- "anyOf": [
- {
- "additionalProperties": false,
- "properties": {
- "introduction": {
- "maxLength": 20000,
- "type": "string"
- },
- "sections": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "code": {
- "maxLength": 20000,
- "type": "string"
- },
- "heading": {
- "maxLength": 500,
- "type": "string"
- },
- "paragraphs": {
- "items": {
- "maxLength": 20000,
- "type": "string"
- },
- "maxItems": 50,
- "type": "array"
- },
- "steps": {
- "items": {
- "maxLength": 5000,
- "type": "string"
- },
- "maxItems": 50,
- "type": "array"
- }
- },
- "required": [
- "heading",
- "paragraphs"
- ],
- "type": "object"
- },
- "maxItems": 30,
- "type": "array"
- }
- },
- "required": [
- "introduction",
- "sections"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "canonicalUrl": {
- "format": "uri",
- "type": "string"
- },
- "category": {
- "type": "string"
- },
- "collectedAt": {
- "type": "string"
- },
- "contentType": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "indexable": {
- "type": "boolean"
- },
- "language": {
- "enum": [
- "en",
- "zh"
- ],
- "type": "string"
- },
- "product": {
- "type": "string"
- },
- "review": {
- "additionalProperties": false,
- "properties": {
- "pendingChanges": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "policyDays": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "state": {
- "enum": [
- "current",
- "due",
- "pending",
- "not_reviewed"
- ],
- "type": "string"
- }
- },
- "required": [
- "state",
- "pendingChanges",
- "policyDays"
- ],
- "type": "object"
- },
- "reviewedAt": {
- "type": [
- "string",
- "null"
- ]
- },
- "revision": {
- "maximum": 9007199254740991,
- "minimum": 1,
- "type": "integer"
- },
- "source": {
- "additionalProperties": false,
- "properties": {
- "id": {
- "type": "string"
- },
- "name": {
- "type": "string"
- },
- "origin": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "name",
- "origin"
- ],
- "type": "object"
- },
- "sourcePublishedAt": {
- "type": [
- "string",
- "null"
- ]
- },
- "sourceUrls": {
- "items": {
- "format": "uri",
- "type": "string"
- },
- "type": "array"
- },
- "summary": {
- "type": "string"
- },
- "summaryMethod": {
- "type": "string"
- },
- "supersededBy": {
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": "string"
- },
- "updatedAt": {
- "type": "string"
- },
- "verification": {
- "additionalProperties": false,
- "properties": {
- "checkedAt": {
- "type": [
- "string",
- "null"
- ]
- },
- "kind": {
- "enum": [
- "official_documentation",
- "independent_report",
- "software_execution",
- "source_excerpt"
- ],
- "type": "string"
- },
- "limitations": {
- "items": {
- "type": "string"
- },
- "maxItems": 30,
- "type": "array"
- },
- "urls": {
- "items": {
- "format": "uri",
- "type": "string"
- },
- "maxItems": 30,
- "type": "array"
- }
- },
- "required": [
- "kind",
- "checkedAt",
- "urls",
- "limitations"
- ],
- "type": "object"
- }
- },
- "required": [
- "id",
- "product",
- "language",
- "title",
- "summary",
- "contentType",
- "category",
- "revision",
- "canonicalUrl",
- "sourceUrls",
- "sourcePublishedAt",
- "reviewedAt",
- "collectedAt",
- "updatedAt",
- "source",
- "summaryMethod",
- "applicability",
- "verification",
- "body",
- "indexable",
- "supersededBy",
- "review"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "applicability": {
+ "additionalProperties": false,
+ "properties": {
+ "platforms": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 20,
+ "type": "array"
+ },
+ "requirements": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "version",
+ "platforms",
+ "requirements"
+ ],
+ "type": "object"
+ },
+ "body": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "introduction": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "sections": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "heading": {
+ "maxLength": 500,
+ "type": "string"
+ },
+ "paragraphs": {
+ "items": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "maxItems": 50,
+ "type": "array"
+ },
+ "steps": {
+ "items": {
+ "maxLength": 5000,
+ "type": "string"
+ },
+ "maxItems": 50,
+ "type": "array"
+ }
+ },
+ "required": [
+ "heading",
+ "paragraphs"
+ ],
+ "type": "object"
+ },
+ "maxItems": 30,
+ "type": "array"
+ }
+ },
+ "required": [
+ "introduction",
+ "sections"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "canonicalUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "collectedAt": {
+ "type": "string"
+ },
+ "contentType": {
+ "type": "string"
+ },
+ "editorial": {
+ "additionalProperties": false,
+ "properties": {
+ "period": {
+ "additionalProperties": false,
+ "properties": {
+ "cutoffAt": {
+ "type": "string"
+ },
+ "end": {
+ "type": "string"
+ },
+ "start": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "start",
+ "end",
+ "cutoffAt"
+ ],
+ "type": "object"
+ },
+ "productIds": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 7,
+ "type": "array"
+ },
+ "relatedIds": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ "section": {
+ "enum": [
+ "radar",
+ "weekly",
+ "topic",
+ "profile"
+ ],
+ "type": "string"
+ },
+ "sourceDate": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "section",
+ "productIds",
+ "relatedIds",
+ "sourceDate",
+ "version"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "indexable": {
+ "type": "boolean"
+ },
+ "language": {
+ "enum": [
+ "en",
+ "zh"
+ ],
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "review": {
+ "additionalProperties": false,
+ "properties": {
+ "pendingChanges": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "policyDays": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "state": {
+ "enum": [
+ "current",
+ "due",
+ "pending",
+ "not_reviewed"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "state",
+ "pendingChanges",
+ "policyDays"
+ ],
+ "type": "object"
+ },
+ "reviewedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "revision": {
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "source": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "origin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "origin"
+ ],
+ "type": "object"
+ },
+ "sourcePublishedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sourceUrls": {
+ "items": {
+ "format": "uri",
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "summaryMethod": {
+ "type": "string"
+ },
+ "supersededBy": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": "string"
+ },
+ "updatedAt": {
+ "type": "string"
+ },
+ "verification": {
+ "additionalProperties": false,
+ "properties": {
+ "checkedAt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "kind": {
+ "enum": [
+ "official_documentation",
+ "independent_report",
+ "software_execution",
+ "source_excerpt"
+ ],
+ "type": "string"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ "urls": {
+ "items": {
+ "format": "uri",
+ "type": "string"
+ },
+ "maxItems": 30,
+ "type": "array"
+ }
+ },
+ "required": [
+ "kind",
+ "checkedAt",
+ "urls",
+ "limitations"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "product",
+ "language",
+ "title",
+ "summary",
+ "contentType",
+ "category",
+ "revision",
+ "canonicalUrl",
+ "sourceUrls",
+ "sourcePublishedAt",
+ "reviewedAt",
+ "collectedAt",
+ "updatedAt",
+ "source",
+ "summaryMethod",
+ "applicability",
+ "verification",
+ "body",
+ "indexable",
+ "supersededBy",
+ "review"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]botclaw_get_observationsbotclaw_comparebotclaw_get_catalogbotclaw_get_changesbotclaw_get_dailybotclaw_get_itembotclaw_get_latestbotclaw_get_sourcesbotclaw_get_workflowsbotclaw_searchAgent-only long-form publishing: articles, notes, replies and follows under the agent's own byline.
Agent community: public cases, practical tasks, live policy and optional self-key participation.
Protected research briefs, bounded scrolls, and private video feeds for agents.
Agent payments ecosystem intelligence. Scans GitHub/HN/npm across AP2, ACP, x402, MPP, UCP.
Add one secure layer between your agents and this server.