dsa-coach-mcp

Overview Schema Source Related Servers Discussions Admin

review_evidence

Read-onlyIdempotent

Suggests a log-review rating from submission history since last review—again if none accepted, good if first accepted, hard if rejected first—and explains the reason or why no suggestion is possible.

Instructions

Suggest a log_review rating from the user's submissions to this problem since it was last reviewed: again if none was accepted, good if the first was, hard if rejected ones came first. Never easy, since speed is not in the history. Where the platform hides rejected submissions, or nothing was submitted, it suggests nothing and says why; ask the user then. Tell the user the suggestion and its reason, and let them overrule it. Without a handle, uses the one linked with link_account.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "platform": "<platform>",
      "problem_id": "<problem_id>"
    },
    "name": "review_evidence"
  }
}

Input Schema

Name	Required	Description	Default
`handle`	No
`platform`	Yes
`problem_id`	Yes

Output Schema

Name	Required	Description	Default
`since`	Yes
`reason`	Yes
`accepted`	Yes
`platform`	Yes
`problem_id`	Yes
`accepted_at`	Yes
`submissions`	Yes
`suggested_rating`	Yes
`first_submitted_at`	Yes
`rejected_before_accepted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Nov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuine behavior beyond that: the mapping rule (again/good/hard, never easy), the explicit no-data outcome, and the requirement to report the reason and accept an override. That tells the agent this is advisory rather than an applied mutation, which the annotations alone could 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The rule and its exceptions are front-loaded in the first two sentences, and each clause adds information rather than restating the name. It is dense and slightly run-on, with parenthetical justifications ("since speed is not in the history") that are helpful but could be tightened.

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 three-parameter, read-only advisory tool with an output schema, this covers the decision logic, the degenerate case, and the required user communication. The remaining gap is parameter-level detail for platform and problem_id, which the description leaves to inference.

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?

Schema description coverage is 0%, so the description carries the burden. It does explain the optional handle parameter and its fallback ("Without a handle, uses the one linked with link_account"), but platform and problem_id are only implied by "submissions to this problem" — there is no guidance on valid platform values or problem_id format.

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 first clause names a specific verb and output ("Suggest a log_review rating") and scopes the evidence precisely ("from the user's submissions to this problem since it was last reviewed"). It also makes the relationship to the sibling log_review clear, so an agent knows this tool proposes a value that log_review would consume.

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?

Strong on both edges of usage: the rating heuristic tells the agent which suggestion to expect, and the tool's failure mode ("where the platform hides rejected submissions, or nothing was submitted, it suggests nothing and says why; ask the user then") tells the agent what to do instead. It also instructs the agent to surface the suggestion and let the user overrule, which is real workflow guidance. It stops short of explicitly sequencing itself against log_review (e.g., "call this before log_review").

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

Deploy Server