Chinese psychological assessments with guided questions, scoring, PDF reports, and user profiles.
Scored across 12 tools
Most tools have clearly distinct purposes: listing assessments, fetching questions, stepping through answers, scoring, saving, retrieving saved results, generating PDFs, and fetching profiles/examples/schema. The main overlap is among result-oriented tools (score_assessment, get_example_result, get_results, get_report_pdf) and profile-oriented tools (get_user_profile, get_profile_example, get_profile_schema), but descriptions distinguish example vs. real vs. computed vs. PDF use cases.
Almost all tools use consistent snake_case verb_noun naming (get_assessment, list_assessments, score_assessment, save_completed_result, get_report_pdf, etc.). The main deviation is assessment_step, which is noun_noun rather than verb-first, and get_profile_example/get_example_result use slightly different noun ordering.
12 tools is well within the ideal 3-15 range for this domain. Each tool appears to earn its place across assessment discovery, question flow, scoring, saving, retrieval, PDF export, and profile access.
The surface covers the core assessment lifecycle: list assessments, fetch question package/spec, answer step-by-step, score, save completed results, retrieve saved results, generate PDF, and access user/example profiles. Minor gaps exist around deleting or managing saved results, but no major workflow dead end is apparent.
免登录获取下一题、记录本次回答或按题本规则跳题。返回的state由对话端保留，服务端不保存答案。
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | 16暗影抽题种子，可选；重试start时沿用相同种子。 | |
| state | No | 上一步返回的完整状态，保存在AI宿主，继续时原样传回。 | |
| action | Yes | ||
| answer | No | answer操作需要itemId和value；skip操作只需itemId。 | |
| testId | Yes | 测评标识。 | |
| attemptId | No | 本次作答的固定编号。批量计分必填；重试沿用同一编号，保证同分结果一致。 | |
| releaseId | Yes | get_assessment返回的精确题包版本；答题及重试始终使用同一版本。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=false, and destructiveHint=false. The description adds genuinely useful context beyond them: that login is not required and that the server persists no answers, with state round-tripped through the client. However, it omits per-action behavior (what start vs resume returns, retry semantics), so this stays a modest 3.
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 compact sentences with the core capability front-loaded and the statelessness note second; nothing is padded. It could be slightly clearer about the start/resume distinction without growing much.
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 a 7-parameter, nested-object, four-action tool with no output schema, the description is thin: it does not distinguish the four actions' behaviors or describe the returned payload beyond 'state'. An agent has enough to attempt a call but must infer action semantics from the enum.
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 86%, so the schema already documents testId, releaseId, state, seed, attemptId, and the answer object. The description only reinforces the state round-trip concept and adds no syntax or constraint details beyond the schema. Baseline 3 applies when structured fields do the heavy lifting.
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 names three concrete operations (fetch next question without login, record the current answer, skip per booklet rules), so the agent understands this is a stepwise assessment-interaction tool. It is specific about the verbs but never positions itself against siblings like get_assessment or score_assessment.
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?
Usage is only implied: the three described operations map onto the action enum (start/resume/answer/skip), and 'no login' hints at the context. There is no explicit when-to-use, when-not-to-use, or routing to an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建带16暗影品牌的临时网页入口。已在聊天完成计分时，传score_assessment返回的record，打开直接查看该结果；不传record则进入答题。网页下载PDF或保存时普通登录，PDF不自动保存。固定Key平台可用此入口交接刚完成的结果。
| Name | Required | Description | Default |
|---|---|---|---|
| record | No | score_assessment返回的完整record，原样传回。 | |
| testId | Yes | 测评标识，如 mbti-four-preferences 或 shadow16 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description adds real behavioral context beyond that: the link is temporary, PDF download/saving requires ordinary login, and the PDF is not auto-saved. It stops short of stating link expiry or how long '临时' lasts.
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 what is created, then the conditional behavior, then the platform handoff note. Four short sentences, each carrying distinct information, with no 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?
For a 2-parameter tool with a nested object, no output schema, and annotations covering only safety, the description supplies the mode logic and the login/PDF caveats an agent needs. Only the lifetime of the 'temporary' link is left unspecified, which is minor.
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%, so baseline is 3, but the description meaningfully adds semantics for `record`: supplying it yields direct result viewing, omitting it routes to the quiz. That is information the schema alone does not convey; `testId` gains nothing beyond its existing description.
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 concrete verb+resource: creating a temporary branded web entry (带16暗影品牌的临时网页入口), and clarifies the two modes it can serve (view a finished result vs. start the quiz). It references score_assessment as the source of the record, linking it into a workflow, but never explicitly contrasts itself with siblings like get_report_pdf or save_completed_result.
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 an explicit conditional rule: pass the record from score_assessment to open straight into the result view, omit it to enter the quiz, and notes the fixed-Key platform handoff case. This is clear when-to-use guidance, though it does not state when another tool (e.g., get_report_pdf) would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
免登录获取原题包与答题规格。在聊天中使用assessment_step逐题作答，再由score_assessment按原算法计分。
| Name | Required | Description | Default |
|---|---|---|---|
| testId | Yes | 测评标识，如 mbti-four-preferences 或 shadow16 | |
| releaseId | No | 从题包或答题状态取得的原版本标识；同次答题保持不变。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds meaningful context beyond them: '免登录' (no login required) and the intended downstream workflow with assessment_step and score_assessment.
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, front-loaded with the primary purpose, then the workflow. No wasted text; every clause earns its place.
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?
No output schema exists, but the description conceptually explains what is retrieved ('原题包与答题规格') and how to proceed. It does not detail the return structure or parameter usage, though the annotations and full schema coverage reduce the burden.
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 100%, so testId and releaseId are fully documented in the schema. The description adds no additional parameter meaning, making the baseline 3 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 states a specific verb and resource: '免登录获取原题包与答题规格' (retrieve the original question pack and answering specifications without login). It distinguishes the tool from siblings by explicitly naming assessment_step for answering and score_assessment for scoring.
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 clearly describes the workflow context: use in chat with assessment_step to answer each question, then score_assessment to score. However, it does not explicitly compare against retrieval alternatives such as list_assessments or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取标明为示例的完成结果，用于接入体验。
| Name | Required | Description | Default |
|---|---|---|---|
| testId | Yes | 测评标识，如 mbti-four-preferences 或 shadow16 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that the payload is example/sample data rather than a real user result, which is useful context, but it says nothing about what the response contains or whether an example exists for every testId.
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?
A single short sentence with zero filler, front-loading the action and resource before the purpose clause. Nothing to trim.
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 a simple one-parameter read with no output schema, the definition covers the what and the why but not the return shape or behavior when no example exists for a given testId. Adequate but leaves the agent guessing about output content.
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?
Only one parameter with 100% schema description coverage; the schema already documents testId and provides example values (mbti-four-preferences, shadow16). The description adds no meaning beyond the schema, so the baseline 3 applies.
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 (读取/read) and resource (标明为示例的完成结果 — the completed result marked as example), which distinguishes it from get_results (real results) and get_profile_example (profile example). It does not explicitly name those siblings, so the differentiation is inferred rather than stated.
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?
"用于接入体验" implies the tool is for integration/onboarding trials rather than real data retrieval, which gives implicit usage context. It names no explicit alternatives (e.g., get_results for real data) and states no when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
免登录读取模拟人物的综合分析，体验不同特点和状态下的建议。
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | No | ||
| detail | No | ||
| scenario | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the useful non-auth detail ('免登录'), but says nothing about what the returned analysis contains or how the three parameters shape 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?
A single compact sentence covering both purpose and benefit, with the key qualifier '免登录' front-loaded. No filler, though it is arguably too terse to be fully front-loaded with actionable context.
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 is simple and read-only with annotations covering safety, and all parameters are optional. However, with no output schema and 0% parameter coverage, the description leaves the shape of the returned analysis and the effect of each parameter unexplained.
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% and the description provides no parameter information at all. The enum values for caseId are self-describing, but detail ('standard' vs 'evidence') and scenario are left entirely to inference.
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 (读取/read) and resource (模拟人物的综合分析 — a simulated persona's comprehensive analysis), and adds the qualifier 免登录 (no login required). This distinguishes it from get_user_profile and get_assessment, though it never explicitly names those siblings.
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?
Implies usage through '免登录' and '体验不同特点和状态下的建议' — i.e. use it to preview/demo suggestions when no authenticated profile is available. No explicit when-not conditions or named alternatives are given, so the agent must infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
免登录查看用户综合分析的领域、使用场景、算法版本及Skill入口。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the call requires no authentication, which is an operational fact an agent needs. It stops short of describing freshness, caching, or response shape.
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?
A single sentence with no filler, front-loading the authentication exemption and then enumerating exactly what is returned. Every element earns its place.
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 carries the burden of telling the agent what comes back, and it does list the returned categories. It would be stronger if it explained how the returned schema relates to the sibling profile-reading tools, but for a zero-parameter read-only call it is essentially 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?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond the fact that no input is needed, which the empty schema already makes obvious.
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 action (view) and resource (the comprehensive-analysis structure/schema), and enumerates the contents returned: domains, use cases, algorithm version, and Skill entry. It is clear on its own, but it does not differentiate itself from close siblings such as get_profile_example or get_user_profile, so the agent must infer the distinction.
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 phrase '免登录' (no login required) hints at the context in which this tool is appropriate, implying it is the right choice in unauthenticated scenarios. However, it never states when to prefer this over get_profile_example / get_user_profile, nor any exclusion, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用户登录授权后，为刚完成的record或已保存结果生成PDF。不自动保存结果。example仅用于接入示例。
| Name | Required | Description | Default |
|---|---|---|---|
| record | No | score_assessment返回的完整record，原样传回。 | |
| testId | Yes | 测评标识，如 mbti-four-preferences 或 shadow16 | |
| example | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false), so the bar is lower. The description adds genuinely useful context: an authorization requirement and the fact that the result is not auto-persisted. It does not, however, explain why this is not read-only or what the PDF response looks like.
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 short sentences with the auth precondition and purpose front-loaded; there is little waste. It is terse to the point of under-specification rather than bloated.
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 should describe the return (URL, base64, file path?), but it does not. It also leaves the record/testId input selection and nested-object requirements unexplained, which matters for a 3-parameter tool with a nested object.
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%; 'record' and 'testId' are already documented. The description compensates by explaining the otherwise-undocumented 'example' flag ('only for integration examples') and by clarifying the record's origin. It still does not clarify the record-vs-testId relationship (testId required, record optional).
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 (generate a PDF report) and distinguishes two input scenarios ('just-completed record' vs 'saved result'). It is clear what the tool produces, though it does not contrast itself against siblings like get_results or save_completed_result.
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 a precondition ('after user login authorization') and two applicable scenarios, plus the note that results are not auto-saved. However, it never says when to prefer this over alternatives or how the record/testId inputs select the mode, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用户登录授权后，读取其已保存的完成结果、来源和版本。
| Name | Required | Description | Default |
|---|---|---|---|
| testIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the meaningful extra that results are user-scoped and require login authorization, but says nothing about pagination, empty-result behaviour, or how multiple saved results are ordered.
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?
A single tight sentence with no filler, and the authorization precondition is front-loaded ahead of the payload description. It could have spent one more clause on the testIds filter without becoming bloated.
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, and the description compensates partially by naming the returned content (results, sources, versions). It still omits the shape of the response (single vs list), what happens with no saved results, and the role of the only parameter, so it is not fully sufficient for a read tool returning structured data.
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% at the parameter level, so the description must compensate and it does not — testIds is never mentioned. It is unclear whether passing testIds filters the results or whether omission returns all saved results, which is exactly the ambiguity an agent needs resolved before calling.
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 a specific resource (已保存的完成结果、来源和版本), so the agent knows this returns persisted results rather than live computation. It does not explicitly contrast with near-neighbours like get_example_result or get_report_pdf, leaving the boundary to be inferred.
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 precondition "用户登录授权后" establishes that an authenticated user context is required, which is useful routing information. However, there is no statement of when to prefer this over get_example_result or get_report_pdf, and no exclusion of cases such as empty history or unauthenticated callers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
综合用户已授权的多套评测，获得整个人的特点、组合判断、场景建议及追问。
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | standard | |
| domains | No | ||
| testIds | No | ||
| scenario | No | general |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the tool aggregates MULTIPLE authorized assessments rather than fetching one profile, which is important behavior a bare name like get_user_profile would not convey.
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?
A single tight sentence with no filler, and the aggregation scope is stated first. It is efficient, though it is dense enough that the missing parameter guidance has nowhere to live.
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 usefully sketches the return contents (characteristics, combined judgments, scenario suggestions, follow-up questions), which is a real plus. Against four undocumented parameters and no output schema, however, it remains incomplete for an agent trying to invoke it correctly.
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% and none of the four parameters (detail, domains, testIds, scenario) are explained in the description. Only '场景建议' loosely hints at the scenario parameter; the enum values, the domain filters, and the standard-vs-evidence detail mode are left entirely undocumented.
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 clear action and resource: it synthesizes multiple authorized assessments into a whole-person profile ('综合用户已授权的多套评测，获得整个人的特点、组合判断、场景建议及追问'). This distinguishes it from single-assessment siblings like get_assessment or get_results, though it never names an alternative explicitly.
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?
There is no when-to-use guidance and no routing to alternatives such as get_assessment or get_profile_schema. The phrase '已授权的多套评测' hints that prior authorized assessments are needed, but the agent is not told when this tool is preferable to its many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
免登录查看16暗影当前可玩的测评、题量和版本。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description still adds genuinely new behavioral context: that no authentication is needed and that only currently playable assessments are included, which an agent cannot infer from the annotations or empty schema.
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?
A single short sentence that leads with the access condition and the scope, with no filler or repetition. Every clause 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 a zero-parameter read tool with no output schema, the description does the heavy lifting by naming what comes back (assessments, question counts, versions). It could say more about ordering or whether results are cached, but nothing essential 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 takes zero parameters, so per the rubric the baseline is 4 and there is no schema-level parameter documentation to duplicate or contradict. The description correctly implies no filtering input is required.
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+resource pair (view/list assessments) and even names the payload fields returned (题量 question count, 版本 version), which is far more than a tautology. It does not explicitly contrast itself with sibling get_assessment or the other get_* tools, so it stops short of 5.
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?
'免登录' (no login required) gives a usable condition for reaching for this tool over authenticated siblings, and '当前可玩' scopes it to currently available content. However it never says when to prefer this over get_assessment for details or get_results for data, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用户登录并授权后，将完成摘要保存到同一16暗影账号。保留刚才的record，登录后继续保存，无需重新答题。
| Name | Required | Description | Default |
|---|---|---|---|
| record | Yes | score_assessment返回的完整record，原样传回。 | |
| testId | Yes | 测评标识，如 mbti-four-preferences 或 shadow16 | |
| expectedRevision | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=true, so the mutation profile is partially known. The description adds genuine behavioral context beyond that: it requires login and authorization, and it preserves the record across that boundary so the user need not re-answer. It does not, however, explain the destructive/overwrite semantics or the expectedRevision conflict behavior, leaving a meaningful gap for a destructive write.
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 short overall, but the second sentence ('保留刚才的record，登录后继续保存，无需重新答题') largely restates the first in narrative form rather than front-loading the essential scope. Some redundancy without loss of clarity.
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 a destructive mutation with a nested object parameter, a concurrency token, no output schema and no annotations covering return or failure behavior, the description leaves too much open. It says nothing about revision mismatches, partial/failed saves, or what the save overwrites, which an agent needs before invoking a destructive 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?
Schema coverage is only 67%: record and testId are documented in the schema but expectedRevision is not. The description mentions retaining the record but adds no syntax, format or meaning for any parameter, and it does not compensate for the undocumented concurrency token (expectedRevision), which is the riskiest argument 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 verb and resource ('保存' the completed summary/record), so the basic action is identifiable. However, it frames the tool through a user-flow narrative ('登录并授权后') rather than crisply stating what is persisted, and it never distinguishes itself from the obvious sibling score_assessment, which is only hinted at via '刚才的record'. Purpose is implied rather than precisely scoped.
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 when to call it (after user login and authorization) and notes that the workflow continues without re-answering, which gives usable context. It names no explicit alternative or exclusion, so the agent must infer the ordering relative to score_assessment and assessment_step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
免登录按指定题本的原算法计算结果并返回报告。计分不保存账号结果；用户选择保存或下载PDF时再登录授权。
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | 16暗影首8题结果用basic，48题完整结果用full；经典测评使用full。 | full |
| state | No | assessment_step返回的完整状态，16暗影本人测评必填。 | |
| testId | Yes | 测评标识。 | |
| answers | No | 经典测评的原始答案数组，每条包含题目编号itemId和原选项值value。也可传assessment_step返回的state。 | |
| attemptId | Yes | 本次作答的固定编号。批量计分必填；重试沿用同一编号，保证同分结果一致。 | |
| releaseId | Yes | get_assessment返回的精确题包版本；答题及重试始终使用同一版本。 | |
| completedAt | Yes | 固定完成时间，Unix毫秒；重试沿用同一值。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description adds genuinely new context: no login is required for scoring and results are not persisted to the account, which an agent cannot infer from the annotations alone.
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, no filler, and the core behavior (anonymous scoring, returns report) is front-loaded ahead of the conditional login note.
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 carries the burden of explaining the return value, yet it only says a report is returned without describing its shape. Combined with a 7-parameter nested schema and no mention of failure modes, it is adequate but leaves gaps.
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 100%, so every parameter (stage, state, testId, answers, attemptId, releaseId, completedAt) is already documented in the schema. The description adds no format or usage detail beyond what the schema provides, making the baseline 3 correct.
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+resource: compute results for a given test booklet using the original algorithm and return a report. It implicitly separates itself from save_completed_result and get_report_pdf by noting scoring itself does not persist anything, though it never names those siblings.
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?
Clearly frames the tool as the anonymous scoring step and states that login/authorization only happens when the user opts to save or download the PDF. That gives a usable when-to-use condition without naming the specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
score_assessment4 fields changedInput schema / properties / answers / descriptionPrevious value: -"经典测评的原始答案，以题目编号映射选项值。也可传assessment_step返回的state。"New value: +"经典测评的原始答案数组，每条包含题目编号itemId和原选项值value。也可传assessment_step返回的state。"Input schema / properties / answers / itemsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "itemId": {
+ "type": "string"
+ },
+ "value": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "itemId",
+ "value"
+ ],
+ "type": "object"
+}Input schema / properties / answers / oneOfRemoved value: -[
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "itemId": {
- "type": "string"
- },
- "value": {
- "type": [
- "integer",
- "null"
- ]
- }
- },
- "required": [
- "itemId",
- "value"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "additionalProperties": {
- "type": [
- "integer",
- "null"
- ]
- },
- "type": "object"
- }
-]Input schema / properties / answers / typeAdded value: +"array"assessment_stepcreate_assessment_linkget_assessmentget_example_resultget_profile_exampleget_profile_schemaget_report_pdfget_resultsget_user_profilelist_assessmentssave_completed_resultscore_assessmentHosted MCP app for guided anxiety, depression, and well-being self-checks.
A professional resilience and future-orientation assessment for leaders, executives, and high-perfor
Find psychological self-assessment tests in English, Spanish and Russian, with links to take them.
Free BaZi, I Ching, tarot, Zi Wei and bilingual learning tools with transparent methods. No API key.
Add one secure layer between your agents and this server.