---
title: "Actions and results"
description: "Working with versioned tools."
group: "Product"
order: 4
---

## Deployment addresses

- Documentation: https://ctx4.me/docs.md
- Agent index: https://ctx4.me/docs/agent-index.json
- Console and connections: https://console.ctx4.me/integrations
- MCP: https://ctx4.me/mcp
- HTTP API: https://ctx4.me/v1
- Composio base URL: https://ctx4.me/compat/context4/v1
- OpenAPI: https://ctx4.me/docs/openapi.json
- HTTP/MCP inventory: https://ctx4.me/docs/api-index.json
- Composio routes: https://ctx4.me/docs/compat-routes.json
- Connectors: https://ctx4.me/docs/connectors.json


## Inspect the tool

Check its name, input schema and purpose. The public catalog provides reference information; permitted actions depend on the account.

## Complete the task

Before changing data, check the workspace, account and arguments. Do not rely on an extra confirmation if the client does not provide one.

## Check the result

An operation has a state and a result. Compare the result with the original service; when retrying, consider the selected action's idempotency.

## From an accepted request to completion

An execution can have states `requested`, `queued`, `running`, `retrying`, `succeeded`, `failed`, `rejected` and `cancelled`; see the [Execution schema](https://ctx4.me/docs/api-schemas-1.md#execution) for the current contract's exact enum. Distinguish admission refusal from provider failure. A result response can include a short-lived signed link for a large payload.

Before retrying a change, check the previous call's outcome. The network can fail after a provider has applied a write. For HTTP methods that support it, use one idempotency key per logical operation; raw proxy and mirror need separate care because a retry creates a new upstream call.

The [execution reference](https://ctx4.me/docs/api-executions.md) describes status, result, attempts and cancellation. Cancelling an operation does not promise to roll back a change already applied in an external service.