qorenext-mcp

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 does disclose status values and return data types, but does not explicitly state whether the operation is read-only or if there are any side effects. The verb 'Get' implies a read, but this is not made explicit.

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 sentences with no filler. The purpose, statuses, and return types are stated efficiently and front-loaded, making it easy to parse quickly.

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 presence of an output schema, the return structure is already handled. The description covers the core purpose, statuses, and data categories, but lacks details on error handling or polling behavior. For a simple status-check tool, this is adequately 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 coverage is 100%, giving a baseline of 3. The description adds semantic value by mapping screening_type values to concrete data outputs (organizational hierarchy, company verification, deduplication) and explains the request_id usage context, going beyond the schema's basic property descriptions.

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 it retrieves screening request status and results. It lists specific status values (PENDING/PROCESSING/COMPLETE/FAILED) and data types (hierarchy, verification, dedup), distinguishing it from sibling tools like submit_entities or health_check.

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?

Intended usage is implied ('Check if request is complete') but no explicit when-to-use or when-not-to-use guidance is given. Alternatives like health_check or submit tools are not contrasted, leaving the agent to infer when this tool is appropriate.

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, the description carries the burden of behavioral disclosure. It adds 'No authentication required,' which is a useful safety/accessibility trait, and describes the information returned. It does not detail failure behavior or response format, but for a read-only health check, it is reasonably transparent.

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 concise sentences, each earning its place: what it checks, what it returns, and when to use it. Front-loaded and free of 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 low complexity (0 parameters) and presence of an output schema, the description covers the essential context: purpose, return info, usage, and auth requirement. Nothing critical is missing.

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?

The tool has zero parameters, so the input schema provides no semantics. Per calibration, baseline is 4, and the description adds no param information but doesn't need to since there are none.

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?

Description clearly states it checks MCP server health and retrieves basic server information (name, version, auth method). The verb 'check' and resource 'MCP server health' are specific and distinguish it from sibling tools like get_request_status or submit_entities.

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 says 'Use for connectivity testing and diagnostics,' providing clear when-to-use context. It does not explicitly name alternatives or exclusions, but given the distinct purpose, this is sufficient.

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, the description must disclose behavior on its own. It mentions that it returns entity IDs for tracking, indicating a submission/creation behavior, but does not disclose side effects, async behavior, permissions, or failure modes. This adds moderate transparency but leaves gaps.

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 three sentences, with the first stating the primary action, the second clarifying the purpose, and the third mentioning the return value. Each sentence earns its place with no redundancy or wasted words.

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 single parameter with detailed schema and an output schema that likely covers return values, the description is fairly complete. It explains the tool's purpose and return behavior, but could be strengthened by referencing how to track results (e.g., via get_request_status). Overall, it is adequate for a submission 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?

The input schema covers the 'entities' parameter with 100% schema description coverage, including field names, aliases, required fields, and examples. The tool description itself does not add any parameter-level detail, so the baseline score of 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 clearly states 'Submit companies for address verification' and elaborates with 'Validate company addresses and verify organization legitimacy,' giving a specific verb and resource. It distinguishes the tool's focus on address verification, though it does not explicitly name sibling alternatives.

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 implies usage (use when you need to verify company addresses) but does not explicitly state when to use this tool over siblings like submit_duplicates or submit_hierarchy_creation, nor does it mention exclusions or best practices.

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 bears full responsibility. It mentions file submission but does not disclose behavioral traits such as whether processing is synchronous or asynchronous, any auth or rate limits, data size constraints, or if the operation is destructive. This lack of detail reduces 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?

Two concise sentences front-load the action and follow with detail. No wasted words, though a more structured format (e.g., bullet points) could improve scannability.

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 basic purpose and inputs but omits output schema details (though output schema exists), behavioral context, and any constraints. For a simple submission tool, it is minimally adequate but not complete given the lack of annotations.

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%, baseline 3. The description adds minimal context (e.g., 'account records') beyond the schema descriptions, which already fully explain each parameter. No further semantics are provided.

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 submits duplicate entities from a file, specifying supported formats (JSON, CSV, Excel) and the purpose (deduplication detection). It distinguishes from siblings like submit_entities by focusing on duplicates.

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 implies use for duplicate files but lacks explicit guidance on when to use this tool versus siblings (e.g., submit_entities) or when not to use it. No exclusions or alternatives are mentioned.

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 carries the full burden. It discloses that the tool returns entity IDs for tracking results, suggesting an asynchronous process, but it does not explain whether the submission is durable, how errors are reported, or whether it modifies data. This is adequate but not rich—it conveys the main output but misses details about side effects or job 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?

The description is three short, front-loaded sentences. Each sentence adds value: what is submitted, what it does, and what is returned. There is no fluff or repetition, making it appropriately sized and well-structured.

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 one parameter with a rich schema and an output schema exists, so input/output documentation is largely covered. However, the description lacks usage guidance and deeper behavioral context (e.g., whether it is asynchronous, retryable, or rates-limited). Given the lack of annotations, a bit more detail on execution behavior would make it more complete. This is a minimum-viable score.

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?

The schema description coverage is 100% and already provides detailed field meanings, aliases, examples, and defaults (e.g., crmid defaults to 'CRM-100202'). The tool description adds no additional parameter context beyond what the schema offers, so the baseline of 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 clearly states the tool submits companies for organizational hierarchy creation, identifying parent-subsidiary relationships. This distinguishes it from siblings like address verification and duplicates detection, even without naming them. The verb 'Submit' and resource 'companies for organizational hierarchy creation' are specific and unambiguous.

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 implies the tool is used when you need to identify parent-subsidiary relationships, but it does not explicitly state when to use this tool over alternatives (e.g., submit_address_verification, submit_duplicates) or provide any prerequisites. The use case is implied by the purpose but lacks explicit exclusion or alternative guidance.

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