Actions Reference

Reference for Allye MCP tools and their supported actions.

Allye MCP exposes 12 tools. Most tools are action-based: call the tool through MCP tools/call, set its name, and provide an arguments object whose action selects the operation.

{
  "name": "team",
  "arguments": {
    "action": "team_current"
  }
}

The schemas advertised by tools/list are the authoritative source for argument types and optional fields. The lists below describe the current action vocabulary and the intent of each action.

Protocol initialization versus functional initialization

MCP clients begin with the protocol method initialize. It negotiates the MCP protocol version and capabilities, and Allye uses that exchange to load initial user, workspace, team, and document context. It is not called with tools/call.

Allye also exposes an initialize tool with one functional action, init. Use it when an agent needs an explicit context refresh or when a workflow asks for the initialization instructions again.

`allye_health_check`

This tool has no action field. Call it directly to check whether the connected Allye service is responding and to receive health information.

`initialize`

Action	Purpose
`init`	Explicitly load user context, workspace information, teams, and core or user documents.

`team`

Use this tool to inspect and select the team used by team-scoped actions.

Action	Purpose
`team_help`	Explain the available team actions.
`team_switch`	Select a team by name, prefix, or ID.
`team_list`	List teams available to the authenticated user.
`team_current`	Show the currently selected team.
`team_members`	List members of the selected or explicitly supplied team.

{
  "name": "team",
  "arguments": {
    "action": "team_switch",
    "team_query": "Platform"
  }
}

A multi-team user should select a team explicitly. An action can also accept team_id when a per-call override is useful.

`intelligence`

Semantic memory for decisions, sessions, patterns, incidents, plans, knowledge, and preferences.

Action	Purpose
`memory_save`	Save a memory and resolve related knowledge intelligently. A save can be `created`, `updated`, `superseded`, or `noop`.
`memory_search`	Search memories semantically using a natural-language query.
`memory_graph`	Traverse the knowledge graph around a memory.
`memory_relations`	Inspect relations connected to a memory.
`memory_relocation_candidates`	Find memories that may be ready to move between personal and team context.
`memory_relocation_apply`	Apply an approved memory relocation.
`memory_relocation_dismiss`	Dismiss a relocation candidate.
`memory_preferences`	Read pinned memory preferences for the authenticated user.

Memory sectors are decisions, sessions, patterns, incidents, plans, knowledge, and preferences. Searches can filter by sector, scope (personal or team), tags, and result count, and can request graph or content enrichment.

For memory_save, provide a title, Markdown content, and at least one tag. The sector defaults to knowledge; the resulting scope is derived from the sector by the service. Save results are not a similarity-threshold rejection: an existing memory can be merged, superseded, or recognized as already known.

{
  "name": "intelligence",
  "arguments": {
    "action": "memory_save",
    "title": "Authentication decision",
    "content": "Keep authentication on the same domain to simplify session handling.",
    "tags": ["decision", "authentication"],
    "sector": "decisions"
  }
}

{
  "name": "intelligence",
  "arguments": {
    "action": "memory_search",
    "query": "authentication decisions from previous sessions",
    "sector": "decisions",
    "limit": 5,
    "return_content": true
  }
}

`productivity`

Personal TODOs and follow-up work.

Action	Purpose
`todo_create`	Create a TODO.
`todo_list`	List TODOs, with optional status and pagination filters.
`todo_get`	Retrieve one TODO by ID.
`todo_update`	Update a TODO.
`todo_delete`	Delete a TODO.
`todo_stats`	Return TODO counts and statistics.
`todo_search`	Search TODOs by text.
`todo_overdue`	List overdue TODOs.
`todo_upcoming`	List TODOs with upcoming due dates.
`todo_categories`	List registered TODO categories.
`todo_tags`	List registered TODO tags.
`todo_help`	Explain the available productivity actions.

`work_items`

Work planning and delivery. The supported work item types are epic, feature, story, bug, hotfix, task, spike, and subtask.

Action	Purpose
`work_create`	Create one work item.
`work_list`	List work items with filters and pagination.
`work_get`	Retrieve a work item by ID or key.
`work_update`	Update work item fields.
`work_children`	List the children of a work item.
`work_assign_to_me`	Assign a work item to the authenticated user.
`work_status_next`	Advance an item to the next workflow status.
`work_status_done`	Complete an item directly.
`work_status_set`	Set a specific valid status for the item type. Prefer this when the target status is known.
`work_mine`	List work assigned to the authenticated user.
`work_bulk_create`	Create multiple work items in one operation.
`work_statuses`	List valid workflow statuses for the current team and item type.

Common fields use the work_ prefix, including work_title, work_description, work_type, work_priority, work_category, and work_status. Use parent_key or parent_id to place an item in a hierarchy. work_category is required when creating work items.

{
  "name": "work_items",
  "arguments": {
    "action": "work_create",
    "work_type": "task",
    "work_title": "Document the MCP team flow",
    "work_description": "Explain team selection for multi-team users.",
    "work_category": "backend",
    "work_priority": "high"
  }
}

Status changes have distinct purposes: work_status_next moves forward only, work_status_done completes directly, and work_status_set validates a selected status against the item's workflow.

`docs`

Workspace documentation, pages, folders, and navigation trees.

Action	Purpose
`doc_create`	Create a document or folder.
`doc_list`	List documents with filters and pagination.
`doc_get`	Retrieve a document.
`doc_update`	Update document fields and content.
`doc_delete`	Delete a document.
`doc_roots`	List root-level documents.
`doc_recent`	List recently updated documents.
`doc_analytics`	Read documentation usage statistics.
`doc_children`	List the direct children of a document or folder.
`doc_tree`	Read a document's tree.
`doc_full_tree`	Read the complete documentation tree.
`doc_move`	Move a document to another parent.
`doc_publish`	Publish a document.
`doc_version`	Create a document version snapshot.
`doc_duplicate`	Duplicate a document.

Supported document types are folder, page, api_doc, and guide. When creating a non-folder document, provide doc_emoji as required by the current schema.

`sprints`

Sprint inspection and planning context.

Action	Purpose
`sprint_list`	List sprints for the selected or supplied team.
`sprint_active`	Retrieve the active sprint.
`sprint_get`	Retrieve one sprint by ID.
`sprint_work_items`	List work items belonging to a sprint.

Use team_id, sprint_id, limit, and offset where applicable.

`boards`

Workflow board discovery.

Action	Purpose
`board_list`	List boards for the selected or supplied team.
`board_favorites`	List the user's favorite boards.
`board_get`	Retrieve one board.
`board_columns`	Retrieve a board's columns and status mappings.

board_items is not a current action. To work with individual work items, use work_items.

`skills`

Shared and personal agent guidance, imports, exports, and revisions.

Action	Purpose
`skill_create`	Create a skill.
`skill_list`	List skills available in the current context.
`skill_resolve`	Resolve a skill by slug.
`skill_get`	Retrieve a skill.
`skill_update`	Update a skill.
`skill_delete`	Delete a skill.
`skill_marketplace`	Browse marketplace skills.
`skill_fork`	Fork a skill into the current context.
`skill_export`	Export one skill in a client-compatible format.
`skill_import_github`	Import shared skills from a GitHub repository.
`skill_import_personal`	Import personal skills from a repository.
`skill_import_personal_file`	Import personal skills from supplied files.
`skill_export_merged`	Export selected skills with their dependencies merged.
`skill_create_revision`	Create a revision for a skill.
`skill_list_revisions`	List revisions for a skill.
`skill_submit_revision`	Submit a revision for review.
`skill_review_revision`	Review a submitted revision.
`skill_reopen_revision`	Reopen a revision for further work.

For skill_export_merged, provide skill_ids and a skill_export_format. Supported export formats include cursor, claude, copilot, windsurf, opencode, codex, and gemini.

`api_catalog`

Search product API knowledge stored in the Allye catalog. This capability describes catalogued product information; it is not a general-purpose network client.

Action	Purpose
`api_catalog_search`	Search catalogued product interfaces semantically.
`api_catalog_list`	List catalogued API specifications.
`api_catalog_get`	Retrieve a catalogued API specification.

`user_config`

Personal configuration documents used by the authenticated user.

Action	Purpose
`create`	Create a configuration document.
`list`	List configuration documents.
`get`	Retrieve a configuration document by ID.
`update`	Update a configuration document.
`delete`	Delete a configuration document.
`help`	Explain the available configuration actions.

Unlike the other action-based tools, these action values are intentionally short. They are scoped by the user_config tool name.

Common calling guidance

Call the protocol initialize method through the MCP client before using tools; do not confuse it with initialize(action: "init").
For a multi-team user, call team_list and team_switch before team-scoped writes.
Use natural-language queries for memory_search and api_catalog_search.
Use work_statuses before work_status_set when the valid status ID is not known.
Use doc_full_tree before creating or moving documentation when placement matters.
Ask tools/list for the live JSON Schema when an action's optional arguments are unclear.