The Sentio MCP server defines 21 tools with consistent Zod-based schemas and descriptions. However, the server exhibits significant gaps in definition quality: (1) Descriptions are present but often terse and lack context on WHEN to use tools or WHAT happens after calling them; (2) Many parameters lack detailed constraints (ranges, enums, or format specs); (3) Output schemas are completely undocumented, responses are always JSON strings in a generic text field, with no guidance on field structure; (4) Error handling is minimal, tools catch errors and throw them, but error messages do not guide LLM recovery; (5) The server lacks pagination context and does not cap result sizes; (6) Parameter dependencies and mutual exclusivity are not documented. Naming is consistent (verb_noun style) and descriptive fields are present for most parameters, which prevents this from being a D-grade server, but the lack of output documentation and sparse parameter descriptions prevent a higher score.
Explore the detailed call trace for a transaction including internal calls. Returns a partial result by default with subcalls truncated - use callPath to navigate into specific nested calls (e.g., 'root' for root call, 'root/map_0' for first map call, 'root/map_0/dispatch_0' for first dispatch within that map call).
Output schemas completely undocumented. All tools return responses as JSON strings wrapped in generic text fields. No guidance on response field structure, types, or which fields should be used downstream.
Parameter constraints are vague or missing. For example, saveAlertRule accepts a 'rule' object with passthrough(), providing no schema guidance. executeSql accepts 'parameters' as record<string, any> with no constraint on value types. Time range parameters lack format specs (ISO 8601 vs epoch). No numeric ranges or enum constraints.
Recommendations
Document output schema for every tool. Specify the JSON structure returned, including field names, types, and which fields are safe to chain into other tools. For example: 'Returns {alertRules: [{id: string, name: string, enabled: boolean, ...}], totalCount: number}' instead of JSON.stringify(response.data).
Add enum constraints for known-value parameters. For chainId, accept ['1', '5', '56', '137', ...] with descriptions (Ethereum, Goerli, BSC, Polygon). For networkId in getSuiCallTrace/getAptosCallTrace, enumerate valid network IDs instead of free-form strings.
Expand parameter descriptions to 50 - 100 characters with format and range details. Example: 'Numeric chain ID as string (e.g., "1" for Ethereum mainnet, "5" for Goerli testnet). Do not include "0x" prefix.' Current: 'Numeric chain ID (e.g., '1' for Ethereum)' is too terse.
Implement and document a confirmation pattern for destructive operations. For deleteAlertRule and deleteDashboard, require an explicit confirm: boolean parameter, or return a confirmation_token that must be passed back to execute. Document this in descriptions and error responses.
Enhance error responses with recovery guidance. Instead of throwing raw API errors, catch them and return structured errors: {error: {code: 'NOT_FOUND', message: 'Alert rule with ID abc not found', recoverySteps: ['Check the rule ID', 'Call listAlertRules() to discover available rules'], retryable: false}}.
Document pagination defaults and caps. For every list/query tool, state: 'Default limit: 100, max limit: 1000. Use cursor for large result sets. Returns {items: [...], nextCursor?: string, totalCount?: number}.' Add size/limit parameters with explicit bounds if not already present.
Destructive and write operations (deleteAlertRule, deleteDashboard, importDashboard) lack confirmation or dry-run patterns. No description of what happens or guidance on recovery if called by mistake.
Error handling is minimal. Tools throw errors directly without categorizing them as retryable, user-fixable, or fatal, and without actionable recovery guidance. e.g., 'if (response.error) throw response.error' provides no context.
Tool descriptions lack context on WHEN to use each tool and what differentiates similar tools (e.g., getCallTraceByTransaction vs exploreDetailedCallTraceByTransaction vs getSuiCallTrace/getAptosCallTrace). Descriptions average ~65 chars, below production baseline of 194 chars.
Pagination and result limits not documented. queryEventLog, executeSql, listProcessorSourceFilePaths, and listDashboards accept offset/cursor/limit params but descriptions do not state default limits or max results cap. queryRange accepts arrays of queries with no stated size limit.
Parameter dependencies undocumented. For example, queryRange's queries array contains optional fields (labelSelector, aggregate, functions) with interdependencies not explained. saveAlertRule's 'rule' object structure is opaque (passthrough). Users cannot infer what fields belong in nested objects.
No security or permission documentation. No description of what permissions are required to call each tool, whether credentials are needed, or what scopes apply. Sensitive operations like deleteDashboard and deleteAlertRule have no permission gate documentation.
Parameter names sometimes require IDs (owner, slug, chainId) but descriptions do not explain what these are, how to obtain them, or whether they accept human-readable names. e.g., 'owner' is likely a username or org name, but this is not stated.
Add descriptions to nested object fields. For saveAlertRule's 'rule' parameter, replace z.object({}).passthrough() with a detailed schema listing expected fields (e.g., name: string, condition: object, triggers: array) or reference documentation.
Clarify tool distinctions. Add descriptions explaining when to use getCallTraceByTransaction (simple, no internal calls) vs exploreDetailedCallTraceByTransaction (nested calls, use callPath parameter). Similarly, document when to use chain-agnostic getCallTraceByTransaction vs network-specific getSuiCallTrace/getAptosCallTrace.
Add permission/scope documentation to every tool. For example: deleteAlertRule description should include 'Requires: admin permission on project'. This helps agents understand authorization constraints.
Document owner/slug/chainId parameter formats. Example: 'owner: Project owner username or org slug (e.g., "mycompany"). slug: Project slug as defined in settings (e.g., "analytics-prod").' Avoid opaque parameter names without context.
Implement result size caps. For query tools returning many items (executeSql, queryEventLog, listDashboards), cap default results to 20 - 50 and require pagination for more. Document in the tool description: 'Returns up to 50 most recent results. Use cursor for pagination.'
Add idempotency hints to write operations. Document which operations are safe to retry (idempotent) and which have side effects. For saveAlertRule, clarify: 'Idempotent: calling twice with the same id and rule overwrites the previous version; does not create duplicates.'
Improve tool descriptions to match production baselines (194 chars average). Current descriptions average ~65 chars. Expand with intent/context: 'deleteAlertRule: Deletes an alert rule by ID, preventing further alerts from being triggered. Use this when a rule is no longer needed. Warning: This is irreversible; consider exporting the rule first if you may need it later.'