MCP-native AI SRE. Exposes your production OpenTelemetry problems, traces, and logs over the Model Context Protocol, plus an AI remediation loop that opens a reviewed GitHub fix PR and verifies in production (reopening on regression). Tools include list_problems, get_problem, query_traces, detect_anomalies, and request_problem_remediation. Human-in-the-loop by default — the merge button stays yours.
Scored across 2 tools
signup and verify_email have clearly distinct roles: one initiates the email code flow, the other consumes the code to produce a token. There is no overlap or ambiguity between them.
Both names are lowercase and imperative, but signup is a single-word verb while verify_email follows a verb_noun pattern. The naming is predictable and readable despite the minor inconsistency.
Two tools make sense for a minimal email-code auth flow, but the set feels thin because the descriptions reference additional onboarding tools that are not exposed. It sits at the borderline of being too few.
The pair covers code request and verification, but verify_email instructs the agent to call verify_connection and get_activation_status to finish onboarding, and neither tool exists in this server. This creates a significant gap where the intended workflow cannot be completed.
Create an Aient account from an email address, or get a sign-in code for an existing one, with no browser and no token.
When to use: you have no Aient access token and the user wants a workspace, or an earlier verify_email answered workspace_unavailable or its token expired. Ask the user which email address to use.
What happens: Aient emails a 6-10 digit one-time code to that address. Read the code from that inbox (or ask the user for it), then call verify_email with the same email and the code. An address that already has an Aient account receives a sign-in code from this tool instead of a new account; verify_email then returns a token for that account's workspace, preparing the workspace first if an earlier signup never finished. The emailed code is a Supabase Auth credential: it grants this MCP token, and the same email carries a browser sign-in link, so treat both as secrets.
Limits: a few attempts per minute per address.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the side effects (emails a one-time code), the expected follow-up (call verify_email), and the security implication (code is a Supabase Auth credential to treat as a secret). It also notes rate limits. It does not cover edge cases like invalid email or network failures, but the core behaviors are transparent. A score of 4 reflects strong disclosure that is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headers ('When to use', 'What happens', 'Limits') that front-load the critical purpose and usage, then provide sequential behavioral details. Each sentence serves a distinct purpose; there is no redundancy or filler. The length is justified by the tool's procedural complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter, no output schema, and no annotations, the description provides a thorough walkthrough of the expected flow, including how to obtain the code, the call to verify_email, and the handling of existing accounts. It also covers security and rate limits. It omits a few edge cases (e.g., invalid email format, network errors) but is sufficiently complete for an agent to use correctly. The missing edge cases are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not add any semantic detail about the 'email' parameter beyond the schema's format and pattern. The description mentions 'email address' generically but does not elaborate on constraints, validation, or usage nuances. Given the low coverage, the description was expected to compensate, but it does not, so the score is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement of the tool's purpose: 'Create an Aient account from an email address, or get a sign-in code for an existing one, with no browser and no token.' This clearly identifies the verb, resource, and distinctive constraints, and implicitly distinguishes it from verify_email by describing the flow that uses that sibling. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section is explicit and actionable: it specifies the conditions (no token, workspace desired, or previous verify_email returned workspace_unavailable/expired token) and instructs to ask the user for the email. This gives clear guidance on when to invoke this tool versus alternatives, fulfilling the dimension's requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm the code Aient emailed after signup and receive the access token for this MCP server.
Returns: access_token (a Bearer token for this server, valid for expires_in seconds), organisation_id, and user_id. For an address that already had an account, the token belongs to that account's existing workspace; a workspace that was never prepared is prepared now. Reconnect to this MCP server sending "Authorization: Bearer " on every request. Then call verify_connection and get_activation_status and follow its nextActions to finish onboarding. The token is not refreshable: when it expires, call signup and verify_email again.
Errors: confirmation_expired means the code is too old (call signup again); confirmation_failed means it did not match; workspace_unavailable means the code was accepted but the workspace could not be prepared (call signup again for a new code, never verify_email with the used one).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does so thoroughly: it discloses token expiry and non-refreshability, workspace preparation/idempotency behavior, reconnect requirements, specific return fields, and each error condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bolded sections for the outcome and errors. Every sentence carries operational meaning, though the error details and follow-up instructions could arguably be condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with no output schema and no annotations, this description is complete: it covers inputs, outputs, auth, lifecycle, error handling, and next steps. An agent has everything needed to call and respond to this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but both parameters are self-evident from their names and the schema patterns. The description clarifies that `code` is the emailed confirmation code, though it does not explicitly describe `email` beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Confirm'), specific resource (the code Aient emailed after signup), and the outcome (receiving an access token). It clearly distinguishes this from the sibling `signup` by describing the post-signup verification step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames when to call it (after signup), what to do after success (reconnect, call verify_connection and get_activation_status), and what to do on failure (call signup again for expired codes, never reuse a consumed code). This is strong workflow-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
signupverify_email
Add one secure layer between your agents and this server.