@baselab-me/signals-mcp

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

Annotations cover safety profile (destructive: false, openWorld: true). Description adds critical behavioral context: it returns 'unsigned transaction calldata' (output format) and establishes the two-phase execution model (prepare vs submit). Parameter descriptions disclose the EIP-712 payment signature requirement for the second call, though the main description could emphasize this multi-call flow more prominently.

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?

Two efficient sentences with zero waste. Front-loaded with core purpose ('Prepare a signal coin...'), followed by return value specification, then workflow instruction. Every word earns its place.

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?

Given 11 parameters with complex nested pairing objects and a two-call payment authorization flow, the description covers the essential on-chain/Base chain context and submission workflow adequately. No output schema exists, so return value disclosure in the description is appropriate. Minor gap: the main description doesn't explicitly surface the payment authorization flow described in the paymentSignature parameter.

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 has 100% description coverage (baseline 3). Description elevates this by adding 'Base chain' context (crucial for interpreting address parameters) and 'unsigned transaction calldata' (explains the paymentSignature/paymentAuthorization parameter purpose). The reference to 'upload_signal_media first' in the url parameter schema also adds workflow context.

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 specific verb 'Prepare' with resource 'signal coin' and scope 'Base chain'. It clearly distinguishes from sibling 'submit_transaction' by stating this returns 'unsigned transaction calldata' whereas the sibling 'completes the post on-chain', establishing a clear preparatory role.

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?

Explicit workflow guidance: 'Pass the result to submit_transaction to complete the post on-chain' establishes the exact sequence. Also references sibling 'upload_signal_media' in the url parameter description for handling local files, showing clear sibling differentiation.

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