GlobalSource Partners MCP Server

search_research_entities

Read-onlyIdempotent

Search research entities by name or approximate name.

Use this tool whenever a user refers to an entity by name and a research entity UUID is needed.

Results are ranked by match quality and include the research entity UUIDs required by other research tools.

When multiple results are returned, review the entity name, description, match type, match confidence, and available research count to determine the most appropriate entity before using its entity_uuid in another tool.

This tool only searches existing research entities and does not create or modify data.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return. Minimum 1, maximum 50, default 10.
`query`	Yes	The entity name or approximate entity reference to search for.

Output Schema

TableJSON Schema

Name	Required	Description
`limit`	Yes	The maximum number of matching research entities requested.
`results`	Yes	The matching research entities, ordered by match confidence.
`queried_name`	Yes	The normalized version of the query used to search for research entities.
`total_results_count`	Yes	The total number of matching research entities found before applying the result limit.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value by explaining that results are ranked by match quality and include contextual fields, and reinforces that the tool does not modify data. This goes beyond the annotation hints without contradicting them.

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 structured into clear segments: main action, usage trigger, result format, and selection guidance. While slightly verbose, every sentence contributes useful context. It could be tightened by removing the redundant 'does not create or modify data' line, but it remains appropriately sized.

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

Completeness4/5

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

The tool has an output schema, so return values are covered. The description covers when to use it, what results look like, and how to choose the best match. It lacks details about default limit behavior, but that is in the schema. Overall, it gives enough context for correct use.

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

Parameters3/5

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

Input schema provides 100% parameter descriptions, so baseline is 3. The description adds minimal extra parameter semantics, only implying that 'query' supports approximate names. It does not elaborate on 'limit' beyond the schema.

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 clearly states the tool's purpose: search research entities by name or approximate name. It distinguishes itself from siblings like search_research_posts by focusing on entities broadly, and specifies that it returns UUIDs needed by other research tools.

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 provides explicit guidance on when to use the tool ('whenever a user refers to an entity by name and a research entity UUID is needed') and gives detailed instructions on how to select the correct result from multiple matches. No exclusions are needed given the clear use case.

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 tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: search entities by name, search posts by entity UUIDs, read a post by UUID, and read an author by UUID. The descriptions clearly delineate their purposes and include explicit cross-references, making misselection unlikely.

Naming Consistency5/5

All tool names follow a strict verb_noun pattern with a consistent 'research_' prefix: read_research_author, read_research_post, search_research_entities, search_research_posts. The verbs 'read' and 'search' accurately reflect retrieval operations, and naming is uniform.

Tool Count5/5

With 4 tools, the server is well-scoped for a read-only research retrieval domain. Each tool serves a necessary function in the entity-based research workflow, and the count is neither thin nor bloated.

Completeness5/5

The tool set covers the full research retrieval lifecycle: entity discovery (search_research_entities), content discovery (search_research_posts), and content retrieval (read_research_post, read_research_author). The dependency hints ensure agents can complete workflows without dead ends, and the read-only scope needs no CRUD operations.

Resources

Need Help?