current_rms_get_memberFetch one member (organisation, contact, venue or user) with its addresses, emails, phones, links, linked parent/child members and custom fields. Current RMS: GET /members/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| member_id | Yes | The member id. |
Changes observed during successful MCP inspections.
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered, but the description adds valuable detail about what the response contains (addresses, emails, phones, links, parent/child members, custom fields). It does not mention error behavior such as a missing/unknown id, which keeps it short of a 5.
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?
One sentence plus the API endpoint reference, front-loading the verb and resource with zero filler. Every clause earns its place by naming retrievable sub-fields.
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?
With no output schema, the description usefully enumerates the returned payload components, which is exactly the compensation needed for a single-param read tool. It is nearly complete; only error/not-found semantics are unspecified.
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 coverage is 100% and the sole parameter member_id is documented in the schema, so the structured field already carries the meaning. The description's GET /members/{id} restatement adds no syntax or format detail beyond what the schema provides, making the baseline 3 appropriate.
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?
States a specific verb (Fetch) and resource (one member) and enumerates the entity types it covers (organisation, contact, venue, user). The 'one member' framing clearly distinguishes it from the sibling list_members and create/update_member tools.
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 singular resource implies 'use when you have a known member id', which is adequate for a by-id getter, but it never explicitly contrasts with list_members or states the precondition that a valid member_id must already be known. Usage is implied rather than stated.
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.