Skip to main content
Glama

GlobalSource Partners MCP Server

by com.globalsourcepartners
OverviewDiscussionsAdmin

search_research_posts

Read-onlyIdempotent

Search published research posts associated with one or more research entities.

This tool requires research entity UUIDs. If only entity names are known, first call search_research_entities to obtain candidate research entities and their UUIDs.

Use only entity_uuid values copied exactly from search_research_entities results. Never infer, guess, construct, or transform UUIDs from entity names.

Use this tool only after selecting the most appropriate research entity from the search_research_entities results.

Examples:

  • To find research about "United States", first call search_research_entities with "United States", review the returned matches, select the most appropriate entity, and then call this tool with the selected entity_uuid.

  • To find recent research about multiple entities, pass all selected entity_uuid values in research_entity_uuids.

  • To retrieve the next page of results, pass the previous response's next_cursor as cursor.

Results can be filtered by publication date and retrieved using cursor-based pagination.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of posts to return. Minimum 1, maximum 50, default 25.
orderNoSort results by publication time. Use 'published_descending' for newest first or 'published_ascending' for oldest first. Default is published_descending.
cursorNoPagination cursor returned by a previous response. Use this to retrieve the next page of results.
published_afterNoOnly return posts published after this timestamp. Provide a complete RFC 3339 timestamp including a timezone, for example 2026-08-01T00:00:00Z. Date-only values such as 2026-08-01 are not accepted.
published_beforeNoOnly return posts published before this timestamp. Provide a complete RFC 3339 timestamp including a timezone, for example 2026-08-01T00:00:00Z. Date-only values such as 2026-08-01 are not accepted.
count_total_resultsNoWhether to include the total number of matching posts. Use false unless the total count is specifically needed. Calculating the total count may increase response time for large result sets.
research_entity_uuidsYesOne or more research entity UUIDs to search against. This field is required. At least one research entity UUID must be supplied. Do not pass entity names. If the user provides entity names rather than UUIDs, first call the "search_research_entities" tool and use the returned UUIDs from that tool.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitYesThe maximum number of research posts requested.
orderYesThe sort order applied to the results.
resultsYesThe research posts matching the supplied research entities and filters, ordered according to the requested sort order.
next_cursorYesAn opaque pagination cursor. Supply this value in a subsequent request to retrieve the next page of results. Clients should not attempt to interpret or modify the cursor value. If this field is null, there are no additional pages of results.
published_afterYesThe effective lower publication timestamp used for the search. If no lower publication date filter was supplied, this defaults to the earliest date from which research is available.
published_beforeYesThe effective upper publication timestamp used for the search. If no upper publication date filter was supplied, this defaults to the current date and time.
research_entitiesYesThe research entities used to filter the search results.
total_results_countYesThe total number of matching research posts before pagination was applied. Returned only when count_total_results was requested with true; otherwise null.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / published_after / description
      Previous value: -"Only return posts published after this date and time (ISO 8601 format)."New value: +"Only return posts published after this timestamp. Provide a complete RFC 3339 timestamp including a timezone, for example 2026-08-01T00:00:00Z. Date-only values such as 2026-08-01 are not accepted."
    • addedInput schema / properties / published_after / format
      Added value: +"date-time"
    • changedInput schema / properties / published_before / description
      Previous value: -"Only return posts published before this date and time (ISO 8601 format)."New value: +"Only return posts published before this timestamp. Provide a complete RFC 3339 timestamp including a timezone, for example 2026-08-01T00:00:00Z. Date-only values such as 2026-08-01 are not accepted."
    • addedInput schema / properties / published_before / format
      Added value: +"date-time"
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: it requires exact UUID values, forbids inference or transformation, and clarifies that results come from the selected research entities. This is meaningful added transparency even though annotations carry the safety profile.

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 description is longer than average but well-structured with a clear opening statement, workflow prerequisites, and concrete examples. Some redundancy exists (e.g., the required-field guidance is repeated in both description and schema), but every section earns its place by addressing a distinct operational concern.

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?

Given that an output schema exists and all 7 parameters are documented, the description covers all necessary operational context: prerequisite entity lookup, exact UUID usage, filtering, ordering, and cursor-based pagination. An agent has everything needed to invoke the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds operational meaning beyond the schema by explaining the required workflow around research_entity_uuids, explicitly describing cursor reuse for next-page requests, and showing how filters and pagination fit together. This elevates it above the baseline.

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?

The description states a specific action ('Search published research posts') with a clear resource scope ('associated with one or more research entities'). It clearly differentiates from sibling tools like search_research_entities (searches for entities, not posts) and read_research_post (reads a single post).

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: require entity UUIDs, first call search_research_entities if only names are known, select the most appropriate entity, and never guess or transform UUIDs. It also provides examples covering multiple entities and pagination, making the intended workflow unambiguous.

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

All GlobalSource Partners MCP Server toolsInspect
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.

Resources