Coding Tools

The Coding Tools feature connects Spedy tickets with external AI coding assistants. Instead of copying context manually, hand it over with a single click.

Prerequisites

• The org feature AI Coding Tools must be enabled under Settings → Features (enabled by default, all plans).
• Each user picks their own tools under Account → Coding Tools.

Setting up tools

1. Go to Account → Coding Tools.
2. Enable the tools you use with the toggle next to each entry. No tool is enabled by default.
3. For the Custom tool: enable it and enter your own URL template. Available placeholders: {{prompt}}, {{context}}, {{issue.identifier}}, {{issue.branchName}}.

Supported tools

Web-based: Claude Code, Codex, Devin, Lovable, Replit, v0, Netlify Agents.

Desktop (deep-link): Cursor, Windsurf, Zed, GitHub Copilot, Codex Desktop, Conductor, Factory, Warp.

CLI: OpenCode (copies the shell command to the clipboard).

Custom: Freely configurable URL template.

Ticket header menu

A split button appears in the header of every ticket:

• Left side (primary action): Runs the last-used action. Default: Copy as prompt -- copies the ticket context to the clipboard.
• Right side (dropdown): Opens the menu with all enabled tools and a link to the settings page.

When you click a tool in the dropdown, it is saved as the new primary action. On the next ticket, a single click on the left side is enough.

Customising the prompt template

Under Account → Coding Tools you will find the prompt template as an editable text field. Click the variable chips to insert them at the cursor position.

Available variables

The default template includes an MCP hint that tells the tool to query and update Spedy directly via the MCP server (e.g. tickets_get, tickets_update, tickets_add_comment, knowledge_search). If you prefer a purely static handover, delete that paragraph from the template.

Resetting the template

Click Reset to default to return to the built-in template.

MCP tools for ticket management

When an AI coding assistant connects to Spedy via MCP, it can read and write tickets programmatically. The MCP server exposes tools for the full ticket lifecycle.

Creating and updating tickets

tickets_create and tickets_update accept the complete set of ticket properties:

Custom fields

Use tickets_set_custom_fields to set organization-wide custom field values on a ticket. Supported types: text, number, date, select, and checkbox. Values are validated against the field definition.

Discovery tools

To resolve the IDs needed by the setters, use these query tools:

• labels_list — all org labels with ID, name, color, and ticket count
• milestones_list — board milestones with ID, name, due date, and completion progress
• custom_fields_list — custom field definitions with ID, type, required flag, and select options

Reading tickets

tickets_get returns the full property set including labels, milestone, and custom field values, so reads and writes stay consistent.

MCP tools for the wiki

Reading has been possible for a while — wiki_spaces_list, wiki_spaces_get, wiki_pages_list, wiki_pages_get and wiki_search. Two tools now write as well, so an agent can leave behind what it learned instead of burying it in a ticket comment.

Three things worth knowing before you wire this up:

• content replaces the page body, it does not append. Read the page with wiki_pages_get first and send the complete new text, or everything you left out is gone.
• Nothing is lost. Every update snapshots the previous title and body into the page history, exactly like an edit in the browser — you can revert an agent's edit the same way you revert a colleague's.
• folderId distinguishes "leave it" from "move it". Omit it and the page stays where it is; pass null to move it to the root of the space.

Both tools need the wiki:edit permission and editor rights in that particular space — the same two conditions as for a person. The Agents group has the permission by default; being added to the space is a separate, deliberate decision by an admin. A read-only access token cannot reach either tool.

MCP tools for personal todos

Your personal todo list (/todos) is reachable over MCP too — so your agent can jot down a follow-up, set a reminder or tick something off without you switching to the browser.

The rules are exactly the ones from the web app:

• Private. An agent only ever sees the todos you created or that were delegated to you. Anyone else's todo is reported as "not found".
• Creator decides. If a todo was delegated to you, you (and your agent) can complete it and comment on it, but only its creator can edit or delete it.
• People only. Customer accounts and agent users don't get the todo tools at all, and todos can't be delegated to an agent.
• Tokens keep their limits. A read-only access token can list and read todos but not change them; a token with "no deletes" (the default for agent tokens) cannot call todos_delete.
• Board-restricted tokens still reach your todos. Todos don't belong to a board, so a token limited to certain boards can still read and manage your own todos (never anyone else's). A read-only token can still read them; there is currently no token setting that hides personal todos.
• Delegating to someone else needs a plan with todo delegation and notifies that person — just like in the web app.

MCP tools for Pull Requests and Pipelines

AI agents can also query pull request and CI/CD pipeline data via MCP — the same data that powers the Pull Requests and Pipelines views in the browser.

Listing pull requests

pull_requests_list returns a paginated overview of all pull and merge requests across connected providers (GitHub, GitLab, Bitbucket), scoped to the boards you can access.

Getting pull request details

pull_requests_get returns the full detail of a single pull request by its Spedy aggregate ID (from pull_requests_list), including:

• CI pipeline steps with status, type, and duration
• Reviews with reviewer name, status, and body
• Recent events with type and timestamp

Listing pipeline runs

pipelines_list shows CI/CD pipeline runs grouped by status bucket, mirroring the Pipelines view:

Results include per-bucket counts (needsAttention, running, failed, success, total) so the agent can assess overall CI health at a glance.

All three tools are read-only (SAFE risk level), require the mcp:read scope, and are scoped to the boards the connected user can access.

Context in one call: context_search

An agent that starts on a task usually needs three things at once: the tickets that touch the topic, the documentation pages that explain it, and what the team already learned about it. context_search answers one query across all three and returns the results grouped, each with a short snippet.

The response contains groups.tickets, groups.wiki and groups.knowledge, plus a skipped list that names any group the connected user may not access (for example the knowledge base when the AI Knowledge Base feature is off, or the wiki without the wiki:view permission). Nothing is silently dropped — the agent can tell the difference between "no results" and "not allowed". Each ticket and wiki hit carries a score and a matchType (semantic, keyword or both) so the agent can weigh it.

Semantic ranking

tickets_search, wiki_search and context_search rank by meaning as well as by exact words: Spedy computes an embedding for every ticket (title + description) and every wiki page in the background and fuses the nearest-neighbour ranking with the classic keyword ranking. A query like "customer cannot log in after password reset" finds the ticket titled "Reset-Flow: Session wird nicht erneuert" even though the words differ.

• tickets_search and wiki_search accept mode: "hybrid" (default) or mode: "keyword" (exact substring search, newest first). Hybrid results carry score and matchType; the response reports search.mode / meta.mode and semanticUsed.
• Semantic ranking is active whenever the embedding service is configured for your Spedy instance. Without it — or while it is unreachable — every search falls back to keyword ranking automatically and semanticUsed is false; no call fails or waits because of it.
• New and edited tickets and pages are embedded within about a minute; a background job catches up on anything missed.
• Pagination in hybrid mode: the fused ranking is a single page (pagination.singlePage: true). pagination.total still reports how many tickets match the query's keywords in the boards you can access, so a client can tell "that was everything" from "there is more" — walk the rest by requesting page: 2 and up, which uses keyword mode.

Ready-made prompts

The Spedy MCP server also publishes prompts — server-authored message templates your MCP client can offer as a slash command or from its prompt picker (prompts/list / prompts/get). They bundle the context an agent needs with the working agreement Spedy expects, so you don't have to type it every time.

Prompts follow the same permissions and feature toggles as the tools they draw on: a user without wiki access gets the ticket-only variant of work-on-ticket; review-pr is hidden when the Pull Requests view is disabled. Everything in a prompt that was written by people — ticket text, comments, wiki excerpts, PR descriptions — is clearly marked as data, not instructions, so a comment cannot hijack your agent.

Tips

• Only enable the tools you actually use -- it keeps the dropdown clean.
• Set up MCP integration under Account → MCP so tools can access live data via MCP.
• Use the Custom tool when your preferred tool is not on the list.