Social MCP

Overview Schema Source Related Servers Discussions Admin

social_mcp_check_update

Read-only

Checks the installed Social MCP version against GitHub's stable release, using a cached result unless forced, so users can decide whether an update is needed.

Instructions

Check the installed Social MCP version against GitHub's stable release.

force=true checks now; false uses the six-hour process cache. unavailable means the check failed, not that the installed version is latest. disabled means SOCIAL_MCP_CHECK_UPDATES=false; no request is sent. Offer an update when available; change client configuration only when asked. Never reinstall or remove the account database when updating the package.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "social_mcp_check_update"
  }
}

Input Schema

Name	Required	Description	Default
`force`	No

Output Schema

Name	Required	Description	Default
`status`	Yes
`checked_at`	No
`release_url`	No
`latest_version`	No
`current_version`	Yes
`update_available`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.2Nov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true; the description adds the process cache duration, the meaning of the 'unavailable' and 'disabled' outcomes, the SOCIAL_MCP_CHECK_UPDATES=false environment variable that suppresses the request entirely, and a safety warning not to reinstall or remove the account database during an update. This is exactly the behavioral context annotations cannot convey, and it is consistent with the read-only hint.

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?

Five short lines, front-loaded with the core action, and each subsequent line adds distinct information (caching, outcome states, enablement flag, agent behavior). No redundant restatement of the tool name or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema already existing, the description still clarifies the semantics of the two failure states that an agent would otherwise likely misinterpret as success or a stale version. Combined with the update-safety instructions, nothing an agent needs in order to call and act on this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single parameter 'force' has no schema description, so the description carries the full burden. It defines both branches explicitly, including the consequences for network calls and for the six-hour cache, which is more than the schema alone provides.

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 sentence gives a specific verb and resource: check the installed Social MCP version against GitHub's stable release. This is unambiguous and cannot be confused with any of the threads_* siblings, which operate on posts, accounts, and publications rather than package metadata.

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?

It explains the force semantics explicitly (force=true checks now, false uses the six-hour cache) and gives operational guidance about offering an update and changing client configuration only when asked. It falls short of a full 5 because there is no explicit statement of when the agent should call this tool versus defer, though the cache flag covers the main invocation decision.

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