Make application actions available to assistants

An external tool client reaches declared application operations through MCP.

Make application actions available to assistants

Outside assistants can discover and call selected application actions as tools. Wildo derives their input contracts from resource operations, keeping the integration connected to the same business definitions.

You choose which actions to publish and describe when to use them. Each call still passes through the application’s authorization and service behavior.

Example — Let an assistant find the right task

Publish task lookup and search so an assistant can retrieve current information before answering, rather than relying on text copied into its conversation.

For engineers

Add mcp to an existing resource operation variant. This selected task-resource configuration shows exposure beside the operation’s route variant and role requirement:

operationsConfiguration: {
  [CoreResourceOperation.READ]: {
    variants: [
      {
        variantType: ResourceOperationVariantType.API_CALL,
        isDefault: true,
        roles: [CORE_ORG_ROLES.ORG_MEMBER],
        riskLevel: ResourceOperationRiskLevel.LOW,
        mcp: {
          exposed: true,
          description: 'Fetch a single task by its id, including its title, status, priority, and assignee.',
        },
      },
    ],
  },
},

This belongs inside the existing resource factory declaration, which supplies resource identity and schemas; keep its current imports and other operations. It is not a separate server implementation.

The adapter composes the tool name from resource and operation identifiers and derives its input schema. It advertises collection query arguments using the operation’s allowed filters rather than inventing an independent search contract.

Discover before calling

Use an authenticated MCP client against the deployment’s /mcp endpoint. Request tools/list, then use the returned tool name and inputSchema when constructing tools/call. This JSON-RPC body illustrates a discovered read tool; replace the record ID with a task accessible to the caller:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "tasks__read",
    "arguments": { "taskId": "accessible-task-id" }
  }
}

The client supplies transport headers appropriate to its negotiated revision and a Bearer token issued for that MCP audience. A name in the catalogue is discovery information, not a grant of authority. Dispatch resolves the operation again, authorizes the caller and uses the service layer.

Interpret results at the right level

A successful invocation returns the operation result inside the MCP response. Collection results preserve their pagination shape. Field-validation and business-rule failures can become actionable tool errors; authentication failures remain authentication signals so the client can repair its credentials. Build the integration around the advertised schema, including any value envelope, rather than guessing from a REST example.

The operation’s own declared rateLimit policy also runs on MCP dispatch, keyed to the verified credential in a separate MCP bucket. The transport’s blanket principal throttle is additional; it does not replace that authored policy.

Make application actions available to assistants