MCP server exposes no message template tools, although the OAuth app grants message template permissions

I connected the Front MCP server to Claude Code and it works well for conversations, messages, drafts, comments and tags. Thank you for shipping it.

One gap: there is no way to work with message templates. The OAuth app's Resource permissions grid includes a "Message templates" row with Read, Write and Delete, so I ticked it and re-authorized, but the MCP server still exposes no tool that touches templates. The full tool list I get is: search_conversations, read_conversation, move_conversation, assign_conversation, tag_conversation, update_conversation_status, read_message, send_message, list_drafts, create_draft, update_draft, delete_draft, add_comment, get_attachment, list_channels, list_inboxes, list_tags, list_statuses, list_teammates, list_teams, read_contact, search_contacts, read_account, search_accounts, get_my_identity. The server also advertises no MCP resources.

For comparison, the Core REST API does support templates: GET /message_templates works with an API token carrying message_templates:read, so the capability exists, it is only missing from the MCP surface.

My use case is the ordinary support one. I want the assistant to draft replies using our existing message templates, so answers stay consistent with what I already send by hand, and I want it to create a template when we agree on a new standard answer. Right now I have to keep a separate API token purely for that, which splits the setup in two.

Request: add template tools to the MCP server, for example list_message_templates, read_message_template and create_message_template, gated by the message_templates permissions that the OAuth app already offers. If templates are deliberately out of scope for now, it would help to grey out that row in the OAuth grid the way Namespace access is greyed out, so it does not read as a capability.

Two small documentation suggestions from setting this up, in case they help other people:

• The setup page says to add an OAuth feature to the developer app. It is worth stating explicitly that this is an OAuth feature and not an MCP feature, because "Add feature" offers several types and only the OAuth one carries the redirect URL field that accepts http://localhost/callback.
• Resource permission changes only take effect after re-authorizing, since the scopes are baked into the token when the user accepts. A line saying so would save people a confusing round trip.