The three Analytics tools are added in the Node.js 0.7.0 / Python 0.4.0 source release. Remote deployment and npm/PyPI publication are separate steps. Check your endpoint’s
tools/list for availability.tools/list for the actual tools and schemas.
Plan availability does not grant authorization: API-key scopes, user permissions, access to the target resource, and provider connections still apply.
“Billable” means consuming a Tool Call from your plan allowance, not necessarily an additional monetary charge. Administration and connection diagnostics are non-billable. All 13 skill tools require Plus or above and consume one Tool Call only on success.
Free users can discover skill names, descriptions, and input schemas. Execution is rejected with PLAN_UPGRADE_REQUIRED before accessing skill data. Signing in again does not resolve a plan restriction.
Results vary by tool: Markdown text, text containing JSON, or structured errors. Skill plan denials and operation failures use MCP isError: true. For execution tools, also inspect JSON fields such as status, success, and reason, plus the provider result.
Plans, billing, and Analytics
Normal provider tools are generally billable on success and provider errors, with exceptions such as internal errors. Pre-execution rejection such as a missing account selection is not counted as execution usage. Connection checks record one non-billable parent call regardless of the number of accounts, and retain individual probe outcomes in the diagnostic result.
Unauthenticated requests, unknown MCP tools, and schema validation failures that do not reach execution are not counted as Tool Calls. Newly instrumented tools do not receive retroactive usage history.
Health Check
shanone_health_check
Check MCP connectivity, API-key authentication, and backend health. No provider credentials are tested. No parameters. Pass{}.
Tool Vendor
See MCP overview for version and rollout compatibility. For endpoints that have not been updated, follow their actualtools/list definitions.
shanone_search_tools
Search integration tools by keyword, ranked by relevance. The same response includes input schemas for top candidates, so a result withinputSchema can be executed without a separate schema request. Use shanone_list_service_tools for a complete service listing.
tools, total, query, service, offset, limit, has_more, and next_step instructions. Each tool contains name, service, description, and one of these fields:
The combined inline schemas have a 24,000 UTF-8 byte budget. Results outside the requested top candidates, oversized schemas, and schemas that could not be retrieved use
schemaRef. Required fields and constraints are never removed to fit the budget. This budget covers schemas, not the entire search response.
Schemas reflect the calling user’s parameter policies. Reuse known schemas for subsequent calls in the same user context, refreshing them when they change. Authorization and parameter policies are still enforced at execution time.
For example, if the search result for linear_list_teams includes inputSchema, execute it in the next call:
shanone_list_service_tools
List tools for one service with pagination. Follow subsequent pages to retrieve the full list.shanone_get_tool_schema
Fetch the input JSON Schema when search returnsschemaRef instead of inputSchema, or to refresh a known schema. This tool remains available; it is not required after every search.
Connections
shanone_list_connections
List saved connections visible to the caller. Stored configuration is not proof that authentication still works.supports_account_selection: true can be passed to execute_tool. Multiple-account selection currently supports Gmail. A legacy:<service> ID identifies a single connection for diagnostics; use it with check_connection, not execution account selection. Requires API-key scope integrations:read or all.
shanone_check_connection
Verify saved connections using read-only provider APIs. Omitting service checks all connected services, with pagination.integrations:read and tasks:create, or all, plus permission for the probe tool.
Results include verified, reauth_required, insufficient_permissions, permission_denied, rate_limited, temporarily_unavailable, verification_failed, unsupported, and not_connected. verified means the named read-only probe succeeded, not that every API operation or permission is available. Unsupported probes are not reported as successful.
Execution
shanone_execute_tool
Execute an integration tool. Inspect both the execution envelope and the provider result; completing a tool invocation does not by itself prove the provider operation succeeded.tools/list.
For Gmail, obtain an account ID with list_connections and provide it on each call. Omitting it returns CONNECTION_SELECTION_REQUIRED. To use another account, change the ID on the next call. execution_context_id is no longer supported.
For auth_required / auth_expired, follow the returned connection instructions. For confirmation_required, obtain confirmation and retry with "confirm": true in the same arguments. Usage is recorded under the executed tool’s name, without an additional execute_tool charge or count.
Skill Vendor
All 13 tools require Plus or above and are billable only on success. Skill ownership and resource-sharing permissions still apply.shanone_list_skills
List saved skills, newest first. The query is optional; an empty query lists your saved skills with pagination.shanone_get_skill
Read a skill’s name, summary, and full instructions. The agent follows the instructions itself; this call does not execute the workflow.shanone_create_skill
Create a reusable skill. All three fields must be non-empty. description and body are stored as summary and instructions.shanone_update_skill
Update an existing skill. Only non-empty optional fields are changed; empty strings leave the existing values unchanged.shanone_delete_skill
Permanently delete a skill.shanone_list_skill_files
List additional files bundled with a skill, including paths and sizes. The main instructions are read with get_skill.shanone_read_skill_file
Read a text file bundled with a skill. Binary files return a description instead of their contents; use the dashboard to view or download them.shanone_write_skill_file
Create or overwrite a UTF-8 text file. Missing parent folders are created automatically.shanone_delete_skill_file
Delete one file bundled with a skill.shanone_grep_skill
Search skill files with a regular expression. Results include file paths and line numbers; narrow the pattern if results are truncated.shanone_create_skill_folder
Create an empty skill folder. This is optional before writing files because write_skill_file creates parent folders.shanone_delete_skill_folder
Delete a folder and all files and subfolders inside it. This operation cannot be undone.shanone_rename_skill_path
Rename or move a file or folder. Moving a folder moves its contents. An existing destination is rejected rather than overwritten.Permission Vendor
Permission and parameter-policy management, except list_services, requires Root or an SA2 user delegatedtool-permissions:ManageOthers. Delegated SA2 users cannot target Root users. All are non-billable.
shanone_list_services
List registered service names, display names, and tool counts. No administrator role is required.shanone_list_user_tool_permissions
List a target user’s tool and service permission overrides.shanone_set_user_tool_permission
Allow or deny one tool for a target user. A tool override takes priority over a service override or role default.shanone_set_user_service_permission
Allow or deny the tools of a service for a target user, subject to individual tool overrides.shanone_get_permission_summary
Summarize a target user’s enabled and disabled services and tools.shanone_batch_set_user_permissions
Apply up to 500 service/tool permission operations in one call. Inspect each operation’s result; one failure does not abort the entire batch.Parameter Policies
shanone_get_tool_parameter_policy
Read the argument constraints configured for a target user’s tool. Tool access and allowed argument values are separate controls.shanone_set_tool_parameter_policy
Set or replace one field’s argument policy. Constraints are applied by the server during execution.shanone_delete_tool_parameter_policy
Remove the policy on one field. This does not change the tool’s allow/deny permission.Errors and migration
shanone_create_execution_context, shanone_get_execution_context, and shanone_switch_connection have been removed. Refresh the client’s tool list and migrate to explicit connection IDs.
shanone_get_tool_usage is a design proposal, not an available tool.
Configure your connection.
Analytics
All three tools require Plus, Pro, Team, or Enterprise. API keys authenticate the caller. Analytics authorization uses the live subscription and user policy; no Analytics-specific key scope, permission migration, or key reissue is required. Plan access does not grant user permissions. The existing Root/SA2 policy engine evaluates user/group policies, permission boundaries, and organization controls. No roles or policies are automatically granted by this release.
Organization and caller IDs are resolved server-side; arbitrary user/organization IDs are not accepted. Scope and permissions are checked again for each page. Knowing a log ID does not grant access.
Each successful call consumes one Tool Call, including zero matching records and subsequent pages. Invalid inputs, plan/permission rejection, missing logs, expired cursors, quota rejection, and backend/read-budget failures are not charged. Reservations are canceled on execution failure. Each read is audited without copying the fetched log payloads into its own audit record. The current read is outside its own fixed
as_of window and appears in later usage queries.
shanone_get_tool_usage
Returnstotals, grouped rows, period, as_of, next_cursor, complete, read_consistency, coverage, and warnings. Totals cover the full matching period, not just the displayed page. Counts distinguish successful, failed, unknown-status, billable, and non-billable calls. Stored error and failed both count as failed; missing/unrecognized statuses remain unknown. statistics adds duration samples, average/min/max/p95 and error-category counts for the whole result and each group. Each row has a logs_query with the exact filters, and next_steps suggests a failure search when failures exist. Rows sort by count descending, then key ascending.
shanone_search_tool_logs
Returnslogs, total_count, and the same period/pagination metadata. Logs sort by timestamp descending with log ID as the tie-breaker. Each row contains log_id, timestamp, tool/service, status, duration, billing flag, connection/session IDs, and an error type when available. Each row also includes execution (metadata summary and error guidance), billing (historical reason or explicit unknown), and a ready-to-use detail_query. No request/response bodies or free-text error messages are returned.
Shared parameters for usage and search:
Usage additionally accepts
group_by (tool, service, day; default tool) and IANA timezone (default UTC) for day boundaries. Search additionally accepts status (all, success, failed, unknown), connection_id, and session_id. Different filters are AND-combined; tool_names matches any listed name.
unknown, not assumed complete. Missing legacy statuses remain unknown; missing legacy billing flags use the shared Analytics billing fallback.
Reads are bounded to 50 database pages, 50,000 evaluated records, and a 10-second budget checked between database operations. If the full period cannot be read, READ_LIMIT_EXCEEDED is returned without partial totals or a charge. Narrow the period. complete: true means the bounded query was exhausted, not that all historical or recently ingested events are present.
shanone_get_tool_log
not_stored, unstructured_or_truncated, size_limit, or redacted; unavailable content is not reconstructed. Recognized credential keys, token patterns, and URLs are redacted. Structured payload output is limited to 16 KB per field. Existing provider-specific audit redaction still applies. Legacy IDs that are not directly addressable are returned as LOG_NOT_FOUND; this endpoint does not scan the entire table.
Permission denials include reason; user-policy denials also include required_action to identify the missing action.
Errors use MCP isError: true: PLAN_UPGRADE_REQUIRED, PERMISSION_DENIED, INVALID_ARGUMENTS, INVALID_SERVICE, TOOL_CALL_LIMIT_EXCEEDED, LOG_NOT_FOUND, INVALID_CURSOR, CURSOR_EXPIRED, READ_LIMIT_EXCEEDED, or ANALYTICS_UNAVAILABLE. The local proxies use the same server policy through POST /api/v1/analytics/usage, /logs/search, and /logs/detail.
Reading the response (version 2)
Successful Analytics responses includeresponse_version: 2, query_status: "success", and a short summary. This means the Analytics query succeeded, not that every recorded execution succeeded. A failed Analytics operation uses MCP isError: true and a query_status: "error" error body when it reaches the shared execution policy. Protocol/input validation may reject earlier. Existing fields (totals, rows, logs, status, duration_ms, billable) remain available.
Illustrative search row, abbreviated:
execution.operation identifies the tool and recorded argument count. execution.result_metadata exposes only recorded argument count, input/output byte sizes, output type, truncation flag, and a top-level collection item count when recorded. The summary does not inspect payload text, claim the intended business outcome happened, or infer affected-record counts. A collection count describes a returned top-level list, not how many records an operation changed. Missing metadata is null.
Error guidance comes from the stored classification (rate_limit, timeout, invalid_input, auth_error, internal_error, or unknown). It is a troubleshooting suggestion, not a verified provider-specific root cause or authorization to retry. Success gives error.state: not_applicable; unrecognized execution status gives unknown_execution_status. Metadata alone cannot distinguish an expired credential from every other authorization failure. Free-text error details remain behind include_payload permission and redaction.
Usage statistics.duration_ms contains sample_count, missing_count, average, min, max, p95, and percentile_method: nearest_rank. Only finite nonnegative durations are included; absent/invalid values are not treated as zero. With no samples, numeric statistics are null. statistics.errors counts failures by supported classification, including unknown. Statistics cover the full matching result/group, not just the displayed page. rows[].logs_query preserves scope, billing and tool/service filters; day grouping uses the requested timezone and clamps the day to the original period. Following any suggested query still requires permissions and incurs the normal successful-call charge.
Detail responses add timings, related_execution (session, retry origin, previous tool and parallel group), availability, and optional next_steps. These reflect stored fields only; they do not fetch other logs automatically. Payload availability is not_requested / permission not_checked by default, and requested / granted after explicit authorized inclusion. A suggested payload query does not imply the caller has that permission. Missing detail fields do not prove deletion or retention expiry; those causes are not distinguishable from missing instrumentation. With payload inclusion, request/response states describe what was actually available. Empty stored strings are not_stored.
New execution records persist their billing decision reason:
For older records,
reason is null and reason_state is not_recorded; current pricing is never used to invent a historical reason. decision_source: legacy_default indicates the billing flag itself was absent and the shared legacy fallback was applied. Reasons and top-level collection counts become available for newly written records after the relevant execution service is deployed. Older records are not backfilled.
Response version 2 uses a separate snapshot binding. Cursors created before this output update must be replaced by a new query; existing authorization, read budgets, payload restrictions, and billing rules still apply.
OpenAI integration tools
OpenAI provides 10 integration tools throughshanone_execute_tool: image generation/editing, background research with status/cancellation, transcription, speech generation, and background file analysis with status/cancellation. See the OpenAI tool reference for exact arguments, model constraints, API mappings, output fields and migration notes. These are integration tools, not additional MCP control tools.