Get a specific text message from Follow Up Boss CRM using its unique ID. Returns the full message details for a given text message.
Retrieve a text message by id. (GET /textMessages/{id})
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| extraQuery | No | Extra raw query parameters not explicitly listed above — e.g. FUB custom field filters like custom.ClosingDate on /people or /deals. Keys and values are sent as-is. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It does indicate a read-only GET operation, but it omits details such as error behavior, authorization requirements, or what is returned when the id does not exist.
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 sentence followed by the endpoint, with no redundant wording. Every part contributes directly to understanding the tool's purpose.
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 get-by-id operation, the description combined with the schema is sufficient to invoke the tool correctly. The lack of output schema is compensated by the natural expectation that a 'retrieve' operation returns the resource, though a bit more detail about return shape would be ideal.
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 schema covers one of two parameters (extraQuery) with a detailed description; the id parameter is not described. The tool description only says 'by id', which minimally clarifies the id's role but adds little beyond the schema. With 50% coverage, more compensation would be expected.
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 a specific verb ('Retrieve') and resource ('a text message by id'), which distinguishes it from sibling tools like get_text_message_template or list_text_messages. The inclusion of the HTTP endpoint further reinforces the exact operation.
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 phrase 'by id' implies this tool is used when a specific text message identifier is known, rather than for listing or searching. However, it does not explicitly mention alternatives like list_text_messages or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.