article-review-mcp

by Biogod2020

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation2/5
Multiple tools have overlapping purposes, including explicit compatibility aliases (create/submit_patchset, get_summary/get_feedback, set_decision/set_patch_decision, edit_hunk/edit_patch) and single/batch variants (add_comment/add_comments). This makes it difficult to tell tools apart despite clear descriptions.
Naming Consistency3/5
All tools share the article_review_ prefix, but verb/object patterns vary: some omit objects (open, finalize, create), one uses an adverb (bulk_decide), and compatibility aliases introduce inconsistent verbs for the same action (e.g., set_decision vs set_patch_decision).
Tool Count4/5
At 19 tools, the count is slightly above the ideal 3-15 range, but the patch-based review workflow is inherently complex. The presence of 5 redundant compatibility tools inflates the count unnecessarily, keeping it from a perfect score.
Completeness4/5
The surface covers the full review lifecycle: patch submission, update rounds, decisions, commenting, feedback, pagination, and finalization. Minor gaps exist, such as no explicit patch deletion or comment topic management, but these are workable.
Average 2.9/5 across 19 of 19 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects, required permissions, or side effects. The description offers no behavioral information whatsoever—it doesn't even mention that it performs a write operation or mention any state changes. It is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is so under-specified that it fails to convey any useful information. The brevity comes at the cost of substance, not as a result of tight, informative writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 params, no output schema, no annotations), this description is wholly inadequate. It does not explain the tool's behavior, parameters, or relationship to the aliased tool in any concrete way, leaving the agent with no way to correctly invoke it without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides absolutely no information about any of the 10 parameters, including the 5 required ones. The agent is left without any context for what 'sessionId', 'hunkId', 'status', 'expectedVersion', or 'idempotencyKey' mean in this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a compatibility alias for article_review_set_patch_decision, which indirectly implies its purpose but does not actually describe what the tool does. The agent is left to infer meaning from the sibling tool, and the description fails to state a verb+resource or explain the decision-setting action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the primary tool or any alternatives. The description merely labels it as an alias but does not explain when a user might prefer it, nor does it offer any explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing side effects, permissions, or read-only nature, but it does not. It only says 'load' without indicating whether it modifies anything or requires specific access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, efficiently conveying the core action. It is appropriately structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of two parameters and the need for context on return values or usage, the description is severely incomplete. It lacks explanation of parameters, potential cases, and any output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention sessionId or pendingPolicy, leaving their purpose and interplay completely unexplained. Since schema coverage is 0%, the description adds no meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a document specifically for the Final view, distinguishing it from other get operations like get_feedback or get_page. It uses the verb 'load' and specifies the resource as 'complete assembled document'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives such as get_page or get_summary. The description lacks any conditional context or examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions 'save' and 'replacement', but does not state whether this overwrites the original, the idempotency semantics (though idempotencyKey is in the schema), concurrency controls (expectedVersion), or any potential side effects. The description does not contradict annotations, but it is severely under-informative.
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 a single sentence with no unnecessary words. It is front-loaded with the verb and object. However, it is too brief to be considered fully effective; still, for conciseness alone, it earns points for brevity and lack of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (11 parameters, 5 required, no output schema, no annotations), yet the description provides almost no context. It fails to explain what a 'patch' is in this domain, how the replacement is applied, or what constitutes a valid 'editedText'. The description is far from complete for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. With 11 parameters (5 required), including critical ones like sessionId, patchId, editedText, expectedVersion, and idempotencyKey, the description fails to provide any meaning beyond the raw schema. The agent cannot infer parameter roles from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (save) and resource (a patch), and specifies that it is a human-authored replacement. It is clear enough to distinguish from typical read tools, but does not explicitly differentiate from the sibling tool article_review_edit_hunk, which likely handles a more granular edit. The phrase 'replacement for one patch' suggests a whole-patch edit, but this is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. With 17 sibling tools, the lack of any usage direction leaves the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden, but it only lists core verbs and the target resource. It fails to mention expectedVersion concurrency checks, idempotencyKey requirements, the meaning or consequences of 'reset', or what the response contains.
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 a single front-loaded sentence with no filler, which is structurally concise. However, it is so terse that it omits essential parameter and behavioral context, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, 5 required, no annotations, and no output schema, this one-sentence description is deeply inadequate. It does not explain versioning, idempotency, status semantics, or return behavior, making safe and correct invocation unlikely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 10 parameters. Especially problematic are required fields like expectedVersion and idempotencyKey, and the status enum contains values like 'all', 'pending', 'edited' while the description says 'reset'—leaving the agent without a reliable mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Accept, reject, or reset') on a specific resource ('one patch'), which distinguishes it from sibling tools like article_review_bulk_decide or article_review_set_decision. However, 'reset' does not map cleanly to the status enum values, introducing minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives; only the phrase 'one patch' implies this is for single-patch decisions. It does not mention bulk decision tools, article-level decisions, or any prerequisites such as allowable current patch state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as idempotency guarantees, expectedVersion concurrency checks, or side effects. It merely states the action without elaboration on what happens when marking already-resolved comments or if it requires permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is brief but dangerously under-specified for a complex tool. It omits any structural details, making it under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 params, no annotations, no output schema), the description is grossly insufficient. It doesn't explain return values, error cases, or how required parameters interact, so the agent cannot safely invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no parameter explanations. It does reference the 'resolved' state but doesn't map to required parameters like commentId, expectedVersion, or idempotencyKey, leaving the agent without essential semantics for the 11 parameters.
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 uses a specific verb ('Mark') and resource ('review comment') with a clear scope ('resolved or unresolved'). It distinguishes this from sibling comment tools like add/reply by indicating it toggles resolution state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or when resolution should be toggled, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden, and it only adds a single note about topicId. It does not disclose idempotency behavior, error handling, or implications of the 'expectedVersion' and 'idempotencyKey' parameters, which are critical for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, which technically makes it concise, but it sacrifices important clarity for brevity. It front-loads the main action but provides too little detail for a tool with 10 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For such a complex tool with a nested comments array and no output schema, the description is inadequate. It doesn't clarify batch behavior, partial-failure scenarios, or the meaning of required fields like 'expectedVersion' and 'idempotencyKey', leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, yet the description only hints at the 'comments' parameter being a batch and the use of 'topicId'. Required parameters like 'sessionId', 'expectedVersion', and 'idempotencyKey' remain unexplained, leaving the agent guessing their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it attaches reviewer comments to existing patches, indicating the batch nature and the required topicId context. However, it doesn't strongly distinguish itself from the sibling 'add_comment' (singular) tool, though 'batch' helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of alternatives like 'article_review_add_comment' or 'article_review_reply_comment'. The description does not mention exclusions, prerequisites, or context where this batch tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does not mention the effect of 'reset' (e.g., reverting to pending?), the atomicity of the operation, whether it affects all patches or only those matching criteria, or any side effects like notifications. The description is too terse to understand the behavioral implications of a bulk operation.
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 a single concise sentence that is front-loaded with the main action. It earns its place by being short, but it is under-specified; however, that is a completeness issue, not conciseness. The structure is appropriate for a simple tool description, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, 4 required, no output schema, no annotations), the description is severely lacking in completeness. An agent would not know which parameters are required (sessionId, status, expectedVersion, idempotencyKey) or their significance. The description does not explain return values, error conditions, or the 'reset' action. The tool is clearly not minimal, and the description leaves the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. The description mentions 'all or selected patches', which hints at the 'patchIds' and 'status' filtering, but it does not clarify the role of 'status' as an action (e.g., accept/reject) versus a filter, nor does it explain 'expectedVersion' for optimistic locking, 'idempotencyKey' for retries, 'limit/offset' for pagination, or 'contextMode'. The description is insufficient for an agent to correctly construct a request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (accept, reject, or reset) on a specific resource (patches) in bulk, which is distinct from the single-entity tool 'article_review_set_patch_decision'. However, it does not explicitly mention the 'selected' aspect beyond 'all or selected patches' which is somewhat vague, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when bulk decisions are needed, but it does not provide explicit guidance on when to use this tool versus the singular 'article_review_set_patch_decision' (e.g., for efficiency with many patches) or when to use one over the other. No alternatives or exclusions are given, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Compatibility alias,' which implies it delegates to article_review_edit_patch, but does not explain side effects, permissions, or whether it mutates data meaningful. The description is too sparse to inform the agent about the tool's actual behavior or consequences.
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 a single sentence, which is appropriately concise for a deprecated alias. It front-loads the key fact ('Compatibility alias') and names the target tool. However, it is under-specified for a tool with many parameters, though the alias nature makes brevity acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex schema (11 params, 5 required) and no output schema or annotations. The description only mentions it is an alias, providing minimal context. It does not explain what the tool does, what parameters are needed, or what the return format is. The agent would need to inspect article_review_edit_patch to understand this tool, but that information is not in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 11 parameters (5 required), but the description provides zero parameter information. Schema description coverage is 0%, and the description does not compensate by explaining any parameter meanings or relationships. The agent is left entirely to infer from schema field names, which are not self-explanatory (e.g., 'hunkId', 'editedText', 'idempotencyKey').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Compatibility alias for article_review_edit_patch,' which indicates it is a deprecated alias for another tool. This gives a specific resource (the patch tool) but does not directly state what the tool does (e.g., 'Edits a hunk'). It is not a tautology because it names a sibling tool, but the purpose is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
By calling itself 'deprecated alias,' the description explicitly tells the agent that this tool should not be used in favor of article_review_edit_patch. This is a clear guideline to prefer the alternative, which is more than most descriptions provide. It lacks detail on specific scenarios but effectively signals 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'Open an existing visual patch review' but does not clarify whether this is read-only, what state changes may occur, how pagination works, or what contextMode affects. The word 'existing' rules out creation, but that is minimal context.
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 a single front-loaded sentence with no filler or redundant phrasing. It efficiently conveys the core action and one optional behavior, though it sacrifices behavioral and parameter detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, one sentence is insufficient for an agent to confidently invoke this tool. The description leaves sessionId requirements, return values, pagination semantics, and status/contextMode behavior unaddressed. It provides only a minimal sketch rather than complete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only loosely maps to topicId via 'filter it by comment topic'. sessionId, limit, offset, query, status, and contextMode are left unexplained beyond their schema types and enums. This fails to provide enough meaning for reliable parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open') and object ('existing visual patch review'), which distinguishes it from create/finalize/submit siblings. It also mentions optional filtering by comment topic. However, 'open' is not fully distinguished from the various get/read sibling tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as article_review_get_page, article_review_get_document, or article_review_get_feedback. The description only states that filtering by comment topic is possible; it never explains prerequisites, exclusions, or when another sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'record,' which indicates a write operation, but does not disclose required permissions, idempotency handling, version conflicts (despite expectedVersion in schema), or any side effects. The tool likely modifies state, but this is not explicitly stated. The description is minimal and leaves behavioral assumptions unaddressed.
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 a single clear sentence that immediately conveys the core purpose. It is concise with no filler or redundant phrasing. It earned its place by stating the essential action, though it omits necessary detail for usability. Structurally, it is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, 5 required, no output schema, and no annotations, the one-sentence description is severely incomplete. It does not explain return values, prerequisites, how the parameters relate, or any error conditions. Even the basic operation's scope is vague (e.g., what does 'record' mean exactly? Is it a persistent update?). The presence of unrelated parameters (limit, offset, query) further begs for explanation. This description is insufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – the description mentions none of the 11 parameters, including the 5 required ones. Parameters like implementationReply, expectedVersion, and idempotencyKey are crucial to understanding the operation but are entirely undocumented in the description. The description does not compensate for the schema's lack of inline documentation (the schema itself only provides types, not semantics). With no param guidance whatsoever, this is a major deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (record) and a specific resource (how an editing agent implemented a reviewer comment). It clearly distinguishes from siblings like article_review_add_comment (which adds a new comment) and article_review_resolve_comment (which resolves). The verb 'record' implies a write operation, fitting the tool's purpose. However, it could be more explicit about the target of the reply, but it is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'how an editing agent implemented a reviewer comment' gives context that this is used when an agent has completed an edit in response to a review comment. It implies usage for recording implementation details, but it does not explicitly state when to use this over alternatives like editing a hunk or setting a patch decision. There is no mention of when not to use it or any prerequisites, so it is clear but lacks exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does not explicitly state this is a read-only operation, nor does it explain pagination mechanics, session scoping, or response format. The behavior is only implied by the word 'Load.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear subject and optional condition. It is front-loaded with the primary action and avoids unnecessary words, though it achieves brevity at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, this description is severely underspecified. The agent has no information about what the response looks like, what 'patches' refers to, or how status, query, and contextMode affect results. This is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain the seven parameters, but only hints at topicId via 'optionally showing only one comment topic.' Parameters like limit, offset, query, status, and contextMode remain unexplained, leaving the agent unable to construct valid calls confidently.
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 uses the specific verb 'Load' and identifies the resource as 'paginated patches,' with an optional filter by comment topic. This clearly distinguishes it from sibling tools like get_document or get_feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a basic context (paginated listing) but gives no explicit guidance on when this tool should be used over alternative retrieval tools, nor any exclusions. With multiple getter siblings, the lack of differentiation is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is the constraint 'exactly one primary topic,' which implies a restriction on topic association. No annotations are provided, so the description must carry the burden for side effects, concurrency (expectedVersion), idempotency (idempotencyKey), or other behavioral nuances. The description fails to mention these, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no wasted words. It is front-loaded with the core action and constraint, making it easy to parse quickly. It is appropriately terse, though this brevity contributes to other dimension gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (20 parameters, 6 required, no output schema, no annotations), this description is severely incomplete. It only captures the basic action and one constraint, but does not explain required concurrency and idempotency parameters, the nature of the comment body, allowed enums, or any return behavior. This is far from a complete specification for a tool with such a broad schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 20 parameters and 0% schema coverage, the description must compensate by explaining parameter roles. It only hints at 'reviewer comment' and 'patch' and 'topic,' but does not describe the required parameters like sessionId, expectedVersion, idempotencyKey, or the body content. The description adds marginal value for core parameters but leaves the vast majority of parameters unexplained.
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 action: 'Attach one reviewer comment to a patch under exactly one primary topic.' It uses a specific verb ('attach'), resource ('reviewer comment'), target ('patch'), and a distinguishing constraint ('exactly one primary topic'). This differentiates it from siblings like 'article_review_add_comments' (plural) and 'article_review_reply_comment' (reply context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention a 'when to use' or 'when not to use' context, nor does it reference sibling tools. The implied usage is minimal, but there are no explicit exclusions or criteria for choosing this over other comment-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses key behavioral traits: the round is immutable, unchanged patches carry decisions/comments, and changed patches reset to pending. This is meaningful operational context, though it omits details about idempotency, versioning conflicts, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence conveys the core purpose, immutability, and decision/reset behavior without wasted words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (14 parameters, deep nested patchSet objects, no output schema, no annotations), the description is far too minimal. It covers the central idea but omits lifecycle context, error semantics, concurrency expectations, and parameter meanings, leaving the agent under-equipped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains the patchSet-related semantics (unchanged vs changed patches). Required parameters like sessionId, expectedVersion, idempotencyKey, and the many optional fields are left unexplained. The description does not compensate for the extensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new, immutable review round from the same base document, which is a specific verb+resource pair. However, it does not explicitly distinguish itself from the sibling 'article_review_submit_patchset', leaving some ambiguity about when to use this variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like article_review_submit_patchset. The title implies 'revised patch set', but the description does not clarify the intended workflow or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure, and it barely delivers. The phrase 'complete revised documents' hints at full-replacement (overwrite) semantics, and the deprecated status is helpful, but nothing is said about side effects, expectedVersion conflict behavior, what happens to existing decision state, or whether the operation is destructive. A write tool of this shape needs far more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, zero filler, front-loaded with the most critical signal ('Compatibility', 'complete'). The deprecation directive is immediate and actionable. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity — 11 parameters, 3 required, 3 enums, a composite proposal type, and no output schema — this is under-specified for safe invocation. The deprecation redirect effectively steers agents to the sibling, which is the saving grace, but a complex tool with zero annotations and zero schema coverage needs much more for an agent to use it correctly or to verify it's never needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 0% schema coverage, the description needed to compensate, and it only adds 'complete revised documents' as a hint that `proposal` is the full-document replacement. The cryptic enum values in `contextMode` ('dim_unrelated'), unusual `carryDecisions` semantics, and concurrency-related `expectedVersion` (already required) are all left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as an update to a full proposal document (vs. patch-based), and the title adds 'deprecated'. It explicitly differentiates from the sibling `article_review_update_patchset` by naming it. Held back from 5 because 'Compatibility tool' is jargon-heavy and the core action isn't restated with a crisp verb+resource without inferring from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The directive 'Prefer article_review_update_patchset' explicitly names the alternative and communicates the deprecation stance in one shot. However, it never explains when (if ever) an agent SHOULD legitimately choose this compatibility path, leaving the actual supported scenario implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that this is a compatibility tool and that it creates a review, but it doesn't mention side effects, such as whether it overwrites existing reviews, requires specific permissions, or how it handles the proposal content. The deprecation note is useful but doesn't fully cover behavioral traits.
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 very concise, two sentences, and front-loads the deprecation and preferred alternative. It earns its place by providing critical usage guidance. However, it could be slightly more structured by explicitly listing the key parameters, but it's appropriately sized for a deprecated tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain the return value, the effect of creating a review, or how the parameters interact. The deprecation note and alternative are helpful, but for a tool that still exists, more context is needed for an agent to use it correctly, especially since it's a compatibility tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. The description only mentions 'base + complete proposal' and 'title', but doesn't explain the structure of base/proposal (inline vs workspace_file), the format/locale/topics parameters, or initialPageSize. The schema provides some structure but the description adds no semantic detail beyond the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an article review from a full proposal, and explicitly marks it as deprecated. It distinguishes itself from the preferred alternative by naming article_review_submit_patchset, which helps differentiate it from siblings. However, it doesn't fully elaborate on the exact mechanics of 'create' beyond the title.
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 explicitly says to prefer article_review_submit_patchset, providing a clear alternative and when-not-to-use guidance. It frames this tool as a compatibility tool for base + complete proposal, which gives context on when it might still be used. This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the key behavioral trait: this tool is a passthrough/delegation with identical behavior to get_feedback. That said, it offers zero transparency about side effects (likely none), error behavior, rate limits, or what the return structure looks like—acceptable for an alias, but the burden of behavioral disclosure is otherwise completely unaddressed beyond the 't' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Six words: 'Compatibility alias for article_review_get_feedback.' Zero filler, no redundancy with the schema, front-loaded, and the deprecation context is reinforced in the title. Every element carries meaning, and the trailing period is about the only thing that could have been cut—it's a model of telegraphic precision.
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?
For a deprecated compatibility shim with one obvious parameter and no output schema defined, this is remarkably complete—an agent can determine everything it needs by following the alias pointer to get_feedback. It's missing a note about return format or behavior, but given the tool's design (valid reasons for creating an alias are virtually nil) and the stated deprecation, adding more text could easily do more harm than good. A brief 'returns the same as get_feedback' would have made it a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does nothing to document sessionId—despite the fact that it's a trivially self-explanatory, required string with no enums or nested objects. Since coverage is 0%, the description was supposed to compensate, which it completely fails to do. A strong scorer would have at least mentioned 'the session whose review summary is returned.' Still, the sole parameter name is so self-evident and there are no hidden gotchas (no enums, no nested objects), so the damage is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get review summary (deprecated)' combines a clear verb+resource with a deprecation flag, and the description states it's a 'Compatibility alias for article_review_get_feedback,' which precisely positions it relative to the rest of the family. It's clear and distinguishes itself by pointing to the canonical implementation, though it never says what a review summary actually is (delegating that responsibility to get_feedback). It falls short of a 5 because the purpose of the underlying operation is only inferred from the sibling name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the exact alternative (article_review_get_feedback), which is the single most important piece of usage guidance for a deprecated alias—an agent reading this knows precisely where to route the call. The deprecation signal in the title further implies 'use the other one for new code.' However, it never explicitly states 'for new code, use get_feedback instead' or explains when the alias itself should be used (legacy callers only), leaving the when-to-use guidance slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'safely write' and 'Overwrite requires confirmation, hash checking, and backup', which provides safety-critical context. However, it does not fully disclose behaviors for other modes (write_new_file, export_static_html) or the handling of pending patches, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly front-loaded with the primary purpose, and every word adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 4 modes, no output schema, no annotations), the description is too sparse. It does not explain the meaning of each mode, how pendingPolicy affects output, or what the tool returns. The brief safety note helps, but the overall context is incomplete for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It alludes to several parameters ('preview', 'write', 'overwrite' → mode; 'confirmation' → confirmOverwrite; 'hash checking' → expectedBaseHash; 'backup' → backup), but it does not explain destination, pendingPolicy, or sessionId. This partial coverage is insufficient for a 7-parameter tool.
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 specifies the verb ('Preview or safely write'), the resource ('the article'), and the context ('assembled from accepted, rejected, edited, and pending patches'), making it clear and distinct from sibling tools that handle patch decisions/comments. This goes beyond the title 'Finalize reviewed article' and provides a specific, actionable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool for finalizing the assembled article and mentions 'Preview' as an option before writing, giving usage context. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It adds context about returning compact feedback and filtering by topic, but it does not explicitly state that the operation is read-only or describe any side effects. The return format is also not disclosed, though the word 'Return' implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the core purpose and key filtering behavior. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description needs to be more comprehensive. It covers the basic purpose but omits important parameter details, return value structure, and clear differentiation from many sibling tools. The lack of parameter explanations for 'includeComments' and 'sessionId' leaves gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains 'topicId' via 'Filter by one comment topic' and partially explains 'statuses' with 'pending or rejected', but it ignores 'sessionId' and 'includeComments'. The statuses explanation is also incomplete because the enum allows four values, not just the two mentioned, potentially misleading agents.
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 function with a specific verb and resource: 'Return compact pending or rejected patch feedback'. It also distinguishes itself from sibling tools by explicitly noting it does not return the complete manuscript, making it clear this is for focused feedback retrieval rather than full document access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by targeting 'an editing agent' and stating it filters by comment topic, which suggests when to use it. It also indirectly contrasts with getting the full manuscript, providing implicit guidance. However, it does not explicitly name alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full responsibility for behavioral disclosure. It mentions submission and critical constraints (patches must non-overlap, each patch must include a comment assigned to a topic), which are valuable behavioral details. However, it omits any information about side effects (e.g., whether the submission is final, if it triggers validation, if it overwrites existing content), rate limits, or error behavior. This is a partial disclosure, but the key operational constraints are highlighted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences, front-loaded with the 'Primary article-edit workflow' context, and every word earns its place. It avoids redundancy and conveys the critical usage guidance without clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (nested objects, 8 parameters, no output schema), so the description must provide enough context for correct invocation. It covers the essential workflow (submit base plus patches, comments with topics) but lacks details about return values, error handling, or post-submission behavior. Given the complexity and absence of an output schema, this is a moderate level of completeness—enough to start using it but not enough to anticipate edge cases.
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?
The schema has 8 parameters with 0% coverage in the description, so the description must compensate. It does add meaning for the key parameters: 'base document' (base), 'patches' (patchSet), and 'comments' with 'primary topic' (highlighting the requirement for topicId in comments). However, it does not clarify other parameters such as title, format, locale, topics, baseHash, or initialPageSize. The description gives enough context for the core workflow but leaves several parameters unexplored, so it partially compensates for the schema gap.
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: 'Primary article-edit workflow' with a specific action 'Submit' and resource 'categorized article patches.' It distinguishes from the sibling tools by positioning itself as the primary edit workflow and explicitly contrasts with 'returning a giant rewritten document or textual diff in chat,' which helps an agent choose this over a generic response.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this instead of returning a giant rewritten document or textual diff in chat.' It also clarifies the primary use case and mandates constraints (unchanged base, non-overlapping patches, comments with topics). However, it does not explicitly contrast with sibling tools like 'article_review_edit_patch' or 'article_review_update_patchset,' so the agent may wonder when to use those instead. The word 'Primary' partially addresses this but lacks a clear 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![article-review-mcp MCP server](https://glama.ai/mcp/servers/Biogod2020/article-review-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Biogod2020/article-review-mcp)

Score Badge

Copy to your README.md:

[![article-review-mcp MCP server](https://glama.ai/mcp/servers/Biogod2020/article-review-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Biogod2020/article-review-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Biogod2020/article-review-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server