RigorMed Research MCP

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

Annotations only declare idempotentHint=true, so the description carries most of the burden and delivers: it discloses that no model is started and no task credits are consumed, and warns that materials become frozen once the task begins — relevant side-effect information. It does not explain what happens on verification failure (error vs. partial bind) or the return shape, leaving a small gap.

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 clauses, front-loaded with the action and verification scope, then the side-effect exclusions, then the state constraints. No filler; every clause conveys decision-relevant 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?

The description covers purpose, side effects, and state transitions well, which offsets the absence of an output schema. However, with 0% parameter documentation and no explanation of the failure/verification-result behavior, an agent still lacks enough to call it confidently with correct identifiers.

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% for two required parameters, so the description must compensate and largely does not. The phrase '同一任务上传的文件' hints that task_id scopes a task and upload_id identifies the upload, but neither parameter is named, typed, or given format/relationship guidance (e.g., must upload_id belong to task_id).

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 (核对/绑定 - verify and bind) applied to a concrete resource (uploaded files for a task), and explicitly contrasts with the sibling start_research_task by declaring '不启动模型' (does not start the model). An agent can distinguish it from the other research tools without seeing their schemas.

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 a clear precondition ('上传未成功不能启动' - cannot start if upload failed) and a state constraint ('任务开始后材料冻结' - materials freeze after the task starts), which implicitly frames this as the step before start_research_task. It does not name the sibling tool explicitly or state when NOT to call it, keeping it just short of a 5.

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 exist, so the description carries the full burden; it discloses the safety profile by framing the call as a read ('读取授权账号'), and it preempts two real misreadings: plan=free is not equivalent to unusable, and a positive balance requires no purchase or repeated confirmation. It does not mention auth scopes, rate limits, or error behavior, so it falls 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?

Three sentences, front-loaded with the returned data, then the decision rule, then the free-plan caveat. Every sentence carries operational meaning, though the second sentence is dense enough that it could be split for faster scanning.

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?

There is no output schema, so the description must name the return values; it does so concretely (credits, can_start_research_review, next-step guidance) and adds the interpretation rules an agent needs to act on them. For a zero-parameter read tool, nothing further is required.

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 takes zero parameters, which is the baseline-4 case, so there is nothing for the description to disambiguate. Omitting parameter talk is correct here.

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 opens with a specific verb ('读取') and names the exact resources returned: available credits, the can_start_research_review flag, and next-step guidance. This is clearly distinct from the sibling tools, which all operate on research tasks, uploads, or artifacts, so an agent can route to it 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?

It gives explicit conditional guidance: if credits are available (including gift credits), execute the user's already-stated task directly without recharging, buying a plan, or re-confirming the spend; only prompt for top-up when the balance is insufficient. It does not explicitly say 'call this before start_research_review' or name a sibling as an alternative, which keeps it from a 5.

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?

Annotations already cover read-only/idempotent safety, and the description goes well beyond them: the 200000-byte inline content_text threshold, which MIME types fall back to signed download, exclusions (no input files, internal scripts, cross-task files), and the security rule that signed URLs must not be written into HTML, citation libraries, ZIPs or logs. It also flags the semantic caveat that credit-exhausted artifacts are not full research 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?

Front-loaded with the action and return values, then constraints, then caveats — a logical order with no filler sentences. It is densely packed into few sentences, bordering on run-on, but every clause carries operational 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?

Despite no output schema, the description fully specifies the return shape (download_url, expires_at, GET method, optional content_text), the size/format conditions that determine which shape applies, and expiry behavior. An agent could call this correctly and handle the response without further documentation.

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?

With only 50% schema coverage, the description compensates by constraining artifact_id (must have can_download=true and belong to the same task manifest) and implying task_id scopes that manifest. task_id itself is never explicitly explained, which keeps it below a 5.

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 first sentence names a specific verb and resource (读取…可交付产物) and states exactly what is returned: a short-lived download_url, expires_at and GET method. It also distinguishes the two artifact states (completed task vs. credit-exhausted stop), so the agent knows precisely what it is fetching 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?

It states the qualifying conditions clearly: the artifact must come from a completed or credit-exhausted task, and only artifact_ids with can_download=true in the same task manifest may be used. It even prescribes the recovery path on expiry (re-fetch the same artifact rather than rebuilding the billed task). It stops short of naming sibling tools to use for other situations, so it is not a 5.

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 full burden and does so: stage text is explicitly non-final, completed runs return summary, artifact list, billing settlement status and actually deducted credits, and reservation is clarified as not equal to an actual charge. It also discloses the terminal failure shape — saved and validated summary/artifacts retained with failed status and credits_insufficient reason — so the agent knows what a stopped run looks like and how to present it.

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?

It is front-loaded: purpose and returned fields first, polling protocol second, completion/billing/failure semantics last. Every clause carries information, though the semicolon-chained sentences pack billing policy, return payloads and agent conduct directives into very dense runs, making it harder to scan than a bulleted contract would be.

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 no output schema and no annotations, the description supplies what an agent needs: the return payload at each state (in-progress text, completion summary/artifacts/billing, failure with credits_insufficient) and the polling contract. The remaining gap is provenance of task_id and any statement of idempotency/side effects, which matter for a tool the agent may call in a loop.

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 67%: after_cursor and wait_seconds are already documented in the schema, and the description mostly restates them (the next_cursor→after_cursor handoff and the ~20s wait) rather than adding new syntax or format detail. The required task_id has no description in either the schema or the description text, so the single most important parameter's origin and format remain 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?

The description opens with a specific verb and resource: '读取普通科研任务的真实进展、已完成处理步骤数和可公开的阶段正文', telling the agent exactly what is fetched (progress, completed step count, publicly visible stage text). It implicitly separates itself from start_research_review and get_research_artifact by framing this as a read/poll of task state, but it never names a sibling or clarifies the scope of '普通' (ordinary discipline) versus other task types.

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 gives an explicit operational loop: after showing new stage content, pass next_cursor back as after_cursor and wait up to the 20-second default to avoid empty polls. It also prescribes behavior after a credit-exhaustion stop (show completed work and remaining items, don't claim full completion, don't auto-rebuild the billed task). What's missing is routing guidance — it never says when to call this versus start_research_review, get_research_artifact, or get_account_status.

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?

readOnlyHint=true already signals a safe read, and the description adds meaningful context beyond annotations: querying does not start a research task, the response includes the default item and credit multipliers, and the model_id to use later is the one actually returned. It does not cover caching or rate limits, but for a static catalog that is minor.

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 gating condition is front-loaded in the first clause, followed by what is returned and the downstream id rule. Three dense sentences with no filler, and each one carries a distinct constraint.

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 no output schema, the description still explains what a call returns (enabled models, default, multipliers) and what it does not do (start a task). For a zero-parameter read tool, an agent has everything needed to decide whether to call it and how to use the result.

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 takes no parameters, so the 4 baseline applies. The mention of using the returned model_id is directed at downstream usage rather than this tool's own inputs, so it adds only marginal semantic value here.

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 (read/list) and resource (currently enabled research models), and explicitly lists what is returned: the enabled models, the default item, and credit multipliers. It is clearly distinguishable from write-oriented siblings such as start_research_task and prepare_research_task.

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 gives an explicit trigger (only when the user actively queries or explicitly specifies a model) and explicit non-triggers (general research tasks should use the server default; do not proactively query, recommend models, or ask for confirmation). The alternative path — using the server default — is named directly.

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 only idempotentHint in the annotations, the description carries most of the behavioral burden and does well: it discloses that the model is not started, credits are not charged, uploads use short-lived PUT authorizations plus upload_id, bare OSS paths and arbitrary remote URLs are rejected, and expired links should be retried with the same request. It does not fully describe the lifecycle of the prepared task if upload is never completed, which keeps it 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?

The description is dense but front-loaded: purpose and non-effects come first, followed by per-task requirements and upload/retry handling. Most sentences earn their place, though the semicolon-heavy packing makes it slightly harder to scan than an ideal 5.

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 an eight-parameter preparation tool with no output schema, the description covers the main workflow: what is frozen, what is not started, task-specific file requirements, the returned PUT authorization/upload_id, the follow-up call, and retry behavior. It leaves out prepared-task expiry/lifecycle and more detailed error conditions, so it is strong but not fully 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 description coverage is only 38% across eight parameters, so the description must compensate. It adds important semantics for file roles by tying task_type to required roles (data, manuscript, references, review_comments) and clarifies the upload origin restriction, but it does not explain request_id, research_area, response_language, media-type limits, size limits, or filename uniqueness rules beyond what the schema already says.

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: it freezes the research question, model, and material list for three named task types. It also explicitly distinguishes itself from start_research_task by saying it does not start the model or deduct credits, so an agent can route correctly without opening another 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?

It gives explicit task-type conditions: data_analysis needs at least one data file, citation_audit needs manuscript and references, and paper_revision needs manuscript and review_comments. It also names the next step (complete_research_upload) and the retry rule for expired links, leaving little to infer.

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 full burden and does disclose that execution is asynchronous, that credits are required, and that request_id is an idempotency key frozen across retries. It says nothing about what happens when credits are insufficient, how the caller later retrieves results (get_research_review / get_research_artifact), or failure 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?

Three front-loaded sentences: purpose first, then the credit prerequisite, then the idempotency contract. No wasted text and every sentence carries 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?

For an async launcher with no output schema, the description conveys the async nature, required credits, and idempotency, which is enough to invoke it correctly. It stops short of explaining the result-retrieval path or credit-exhaustion handling, which an agent would need for a full lifecycle.

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 only 20%, so the description must compensate. It adds real meaning for request_id (generate new per question, reuse on retry) and indirectly maps research_area to the three domains, but research_question, response_language, and the model-freezing rule (covered only in the schema) are unaddressed.

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 (异步梳理, asynchronous review) and resource (公开文献、方法差异与研究缺口), plus the supported areas, so an agent understands what the tool produces. It does not distinguish itself from the sibling start_research_task or prepare_research_task, which sound very similar.

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 prerequisites (needs RigorMed credits) and retry semantics (reuse the same request_id), which imply when to call it. It never states when to choose this over the near-identical start_research_task / prepare_research_task siblings, leaving the selection ambiguous.

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?

Annotations only declare idempotentHint=true; the description adds real behavioral context beyond that — that starting incurs credit charges, that it reads files already bound by the prepare step rather than re-uploading, that retries must reuse request_id/task_id, and that no extra confirmation should be requested. It does not discuss latency, async completion semantics, or failure modes, 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?

Every clause carries operational content and the authorization precondition is front-loaded, but the text is a single semicolon-chained block that mixes preconditions, retry policy, and output routing, which slightly hurts 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?

For an 8-parameter launch tool with no output schema, the description covers authorization, model defaults, idempotent retry, billing implications, and where progress and artifacts surface, which is close to what an agent needs. It leaves the semantics of task_type, research_area, and the required file set to the schema.

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?

With schema coverage at 38% across 8 parameters, the description compensates by insisting the payload be identical to the prepare_research_task call and that model_id may be omitted to accept the server default, and by forbidding file/model changes on retry. task_type, research_area, and file roles carry no added meaning in the description, so not a 5.

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 (启动/执行科研文件任务) and pins its identity by saying it takes exactly the same parameters as prepare_research_task, then explicitly excludes the literature-review use case (不是文献调研替代分析), which routes the agent away from start_research_review. An agent can distinguish it from prepare_research_task and start_research_review without opening any 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?

Gives the precondition (任务与积分执行已获授权), the decision rule for optional model selection (未指定模型就采用默认项，不要求选模或重复确认), the retry rule (复用 task_id 与 request_id，不更换文件或模型，不拆成多个扣费任务), and names the alternatives for follow-up (get_research_review / get_research_artifact). Both when-to-use and when-not-to-use are covered.

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