auth_statusCheck if your Medium session is active and valid, identify the logged-in account, and confirm whether it has the membership required to access member-only posts.
Check whether a Medium session is configured and still valid, which account it belongs to, and whether it has a Medium membership (needed for member-only posts).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral context by stating it checks whether the session is 'still valid' and which account it belongs to, implying session expiry and account association. It does not contradict annotations and adds detail about the membership check, which is useful beyond the read-only flag.
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?
The description is a single, well-structured sentence that front-loads the verb 'Check' and packs all relevant checks into a compact list with a parenthetical clarification ('needed for member-only posts'). Every phrase adds value, with no redundant or filler words.
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 status tool, the description covers the essential decision factors: configuration, validity, account identity, and membership. It does not specify the return format, but the absence of an output schema and the simple status-check nature make this acceptable; the agent can infer the result from the described checks.
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 input schema has zero parameters and schema description coverage is trivially 100%. With no parameters to document, the baseline is 4; the description appropriately focuses on the tool's outcome rather than inputs, and there is nothing further it needs to clarify about parameters.
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 uses the specific verb 'Check' and names the exact resource (Medium session/account) and the four things it verifies: configuration, validity, account identity, and membership. This clearly distinguishes it from sibling tools like read_post or follow, which perform actions rather than report status.
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 provides clear context by explaining that membership is needed for member-only posts, implicitly telling the agent when this check is useful. It does not explicitly name when-not scenarios or alternative tools, but no sibling tool competes with this status check, so the guidance is adequate though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.