ghost_get_member

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

No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It only states what data is returned, but does not mention whether the operation is read-only, the behavior on invalid or missing IDs, authentication requirements, or any potential side effects. For a tool with no annotation safety hints, this is a significant gap, similar to the update_drive example.

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 action and resource, then specifies the returned data categories. There is zero fluff and every word adds value. It is appropriately sized for a simple getter with one parameter.

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 getter with one parameter and no output schema, the description covers the core aspects: what it returns (profile, subscription tiers, email history) and the input (via schema). However, it omits error behavior (e.g., what happens if the ID is not found) and does not explicitly state the read-only nature. Given the tool's simplicity, this is nearly complete but has a minor gap around failure modes.

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 covers 100% of the parameters (the 'id' field is described as 'Member ID (24 hex characters)'). The description adds no extra detail about the parameter, so the baseline is 3. Since the schema is sufficient, no compensation is needed.

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 clearly states the action ('Get'), the target resource ('member'), and the scope of what is returned ('detailed profile, subscription tiers, and email history'). This distinguishes it from listing tools like ghost_list_members and other getters such as ghost_get_post or ghost_get_tag. An agent can immediately tell what this tool does and what it serves for.

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 implies usage when you need a single member's details by ID, but it provides no explicit guidance on when to use it versus alternatives like ghost_list_members, nor does it mention any prerequisites or context. The name and verb make it clear enough for a simple getter, but there is no explicit 'when to use' or '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.