Webz.io Blogs segmentation

Aggregate Webz Blogs

aggregate_webz_blogs

Read-onlyIdempotent

Count blog posts instead of returning them (GET /seg_api/blogs).

Aggregates blog posts by blog, author, company and other supported fields. Example: which blogs wrote the most about bitcoin this week.

This is blogs only. It returns buckets with counts, not posts. Each underlying field request costs 1 credit. A response has at most 10 buckets. Returned from_offset values paginate through up to 100 buckets.

q is the same boolean language as search. A space means AND. days is the crawl lookback. Named site lists are q clauses, for example custom_sites_list:hot_sites. Default 7 is the past week. The maximum is 31.

field is the bucket. Default is thread.site,organizations, as two requests. Allowed fields: thread.site, thread.site_suffix, thread.site_full, thread.site_section, thread.site_type, thread.country, thread.url, author, language, site_category, published, locations, persons, person.positive, person.negative, person.neutral, organizations, organization.positive, organization.negative, organization.neutral, trading_symbol.ticker, trading_symbol.exchange. topic, sentiment, category, rating, and trust.* exist on news only and are rejected here.

Separate segmentation arguments: include_syndicated=true includes syndicated copies (default false). webz_reporter=true includes Webz Reporter posts (default false); this is a separate argument, not a q filter. from_offset paginates beyond the first 10 buckets.

Examples:

q=bitcoin days=7
q=bitcoin field=author language:english days=7
q="supply chain" field=persons,organizations days=7

Reference documentation: Segmentation: https://docs.webz.io/docs/webz/news-blogs-forums-segmentation

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "q": "<q>"
    },
    "name": "aggregate_webz_blogs"
  }
}

Input Schema

Name	Required	Description	Default
`q`	Yes	Boolean query with field:value filters. A space means AND; AND, OR and NOT are uppercase. A leading minus also means NOT (tesla -car). Quoted phrases and filter values may contain spaces, for example author:"jane doe". Examples: language:english site:cnn.com country:US. Language values are lowercase full names (hebrew); country values are ISO-2 (GB). Numeric comparisons use > or <, for example domain_rank:<1000. size, sort and days are separate tool arguments.
`days`	No	Lookback in days. Default 7 is the past week. Maximum 31.
`field`	No	Buckets to count. thread.site is the blog, organizations is companies, author is the writer. Default thread.site,organizations runs both. Comma separated.	thread.site,organizations
`from_offset`	No	Returned pagination offset for non-crawled sorts.
`webz_reporter`	No	When true, include Webz Reporter posts. Default false. This is its own argument. webz_reporter:true inside q does not include those posts.
`include_syndicated`	No	When true, include syndicated copies. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses real behavioral traits: credit consumption (1 credit per underlying field request), a hard cap of 10 buckets per response with from_offset paginating up to 100, and the fact that webz_reporter and include_syndicated are separate arguments rather than q filters. It also warns that news-only fields are rejected, which prevents a whole class of failed calls.

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

Conciseness4/5

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

The key differentiator (counts, not posts) is front-loaded and the rest is dense, scannable fragments with worked examples. There is some duplication of the schema — "Default 7 is the past week. The maximum is 31" and the include_syndicated default false are restated verbatim — which costs a little, but nothing is padded prose.

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

Completeness5/5

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

For a 6-parameter aggregation tool with no output schema, the description covers what an agent needs to call it correctly: cost model, bucket ceiling, pagination, allowed and rejected fields, separate segmentation arguments, and a documentation link. The only omission is return-value shape, which is adequately implied by "buckets with counts."

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description earns more by enumerating the ~20 allowed field bucket values and the default "thread.site,organizations" as two requests — information absent from the schema. It also explains q's boolean grammar, days as a crawl lookback with a 31-day max, and the from_offset pagination limit.

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

Purpose5/5

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

"Count blog posts instead of returning them (GET /seg_api/blogs)" names a specific verb (count/aggregate), a specific resource (blog posts), and the endpoint. It further sharpens the identity with "This is blogs only. It returns buckets with counts, not posts," so an agent cannot confuse it with a post-returning search tool even without siblings.

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

Usage Guidelines4/5

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

The description frames the use case with "Count blog posts instead of returning them" and a concrete example ("which blogs wrote the most about bitcoin this week"), which tells the agent when aggregation is the right choice. It also states exclusions for the field argument (topic, sentiment, category, rating, trust.* rejected here). It stops short of explicitly naming a sibling search tool to route to instead, but none are supplied in context, so the guidance is clear if not exhaustive.

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

All Webz.io Blogs segmentation tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.