Skip to main content
@frontmcp/testing extends Jest’s expect with MCP-specific matchers that provide cleaner assertions and better error messages.

Tool Matchers

toContainTool

Check if a tools array contains a tool by name:
Error message example:

Result Matchers

toBeSuccessful

Check if a tool call or resource read succeeded:

toBeError

Check if a result is an error, optionally with a specific error code:
Common MCP Error Codes:

Content Matchers

toHaveTextContent

Check if a result contains text content:

toHaveImageContent

Check if a result contains image content:

toHaveResourceContent

Check if a result contains embedded resource content:

toHaveMimeType

Check the MIME type of resource content:

Resource Matchers

toContainResource

Check if a resources array contains a resource by URI:

toContainResourceTemplate

Check if a resource templates array contains a template:

Prompt Matchers

toContainPrompt

Check if a prompts array contains a prompt by name:

toHaveMessages

Check the number of messages in a prompt result:

Inspecting message role / content

For role and text-content checks on prompt messages, read the message directly. The toHaveTextContent matcher works for tool results; for prompt messages use plain Jest assertions:

JSON-RPC Matchers

toBeValidJsonRpc

Validate JSON-RPC response structure:

toHaveResult

Check that a response has a result (not an error):

toHaveError

Check that a response is an error:

toHaveErrorCode

Check for a specific error code:

UI Matchers

These assert on the rendered UI metadata returned by tools that ship a UI template (see Building tool UI). They run against result._meta / result.content[0].text (the rendered HTML).

Using with Negation

All matchers support .not for negation:

TypeScript Support

The matchers are fully typed. TypeScript will autocomplete matcher names and validate arguments:

Best Practices

Do:
  • Use specific matchers for clearer error messages
  • Combine matchers for comprehensive validation
  • Use error code constants instead of magic numbers
Don’t:
  • Check internal implementation details
  • Use generic .toBe(true) when specific matchers exist
  • Ignore error codes in failure tests