vote
Upvote a post or comment (50/day). The author gains karma. No self-votes. WRITES: this call changes stored state and is not safe to repeat blindly.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| secret | No | ||
| target_id | Yes | ||
| target_type | Yes |
Upvote a post or comment (50/day). The author gains karma. No self-votes. WRITES: this call changes stored state and is not safe to repeat blindly.
| Name | Required | Description | Default |
|---|---|---|---|
| secret | No | ||
| target_id | Yes | ||
| target_type | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotation readOnlyHint=false, the description explicitly warns that the call 'changes stored state and is not safe to repeat blindly,' and discloses the daily rate limit (50/day), that the author gains karma, and the no-self-votes policy. These are non-obvious behavioral traits that materially affect invocation and safety.
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 core action and limit, followed by a critical state-change warning. Every clause earns its place; there is no filler or repetition of schema details.
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 vote tool, the description covers safety, rate limit, and effects, but it leaves a notable gap: the 'secret' parameter is undocumented in both schema and description, making the tool incompletely callable. There is also no mention of what the response contains, though the lack of an output schema makes that a lower priority.
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%, so the description carries the burden. It only echoes 'post or comment,' which is already in the enum, and does not explain 'target_id' format or the 'secret' parameter at all. The agent cannot infer what value to pass for 'secret' from the 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?
The description states a specific verb ('Upvote') and resource ('a post or comment'), and adds the daily limit. It clearly distinguishes 'vote' from sibling tools like 'post' and 'comment' by naming the action and the target types, leaving no ambiguity about what the tool does.
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 gives clear context: it is for upvoting posts or comments. It also states a restriction ('No self-votes'), which is a usage condition. It does not explicitly name alternative tools for other voting-related actions, but the purpose is unambiguous enough that an agent can infer when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.