feat(hex): add Hex MCP Plugin support#286
Conversation
|
@cstavitsky is attempting to deploy a commit to the Sentry Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 148d752. Configure here.
| Internal data access primitive. Executes a Hex query and returns structured | ||
| results. Called by core skills — not intended for direct use. Invoke when you | ||
| need to run a Hex query on behalf of a core skill that has provided a query | ||
| and pattern. |
There was a problem hiding this comment.
Atomic Hex skill is exposed
High Severity
query-hex is packaged as a normal discoverable skill, while type: atomic is not runtime-enforced. It accepts arbitrary query input without requiring org_slug or window, bypassing the scoped get-hex-data flow and allowing broad Hex warehouse queries by authorized users.
Reviewed by Cursor Bugbot for commit 148d752. Configure here.
| - Retry up to **5 times** with approximately **10 seconds** between polls. | ||
| - Continue polling while the thread status is not `IDLE` (i.e., still processing). | ||
| - If still not `IDLE` after 5 retries, return exactly: |
There was a problem hiding this comment.
Bug: The query-hex skill's instructions are contradictory. The steps imply 6 polling attempts, while the guardrails cap it at 5, risking rate limit violations.
Severity: MEDIUM
Suggested Fix
Unify the instructions in query-hex/SKILL.md. Change the text in the steps from "Retry up to 5 times" to "Poll up to 5 times" or "Retry up to 4 times" to align with the guardrail's cap of 5 total get_thread calls per thread. Ensure the error message is also consistent.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/junior-hex/skills/query-hex/SKILL.md#L31-L33
Potential issue: The `query-hex` skill documentation contains conflicting instructions
for polling. The procedural steps direct the LLM to "Retry up to 5 times," which implies
an initial call plus five retries for a total of six `get_thread` calls. However, the
guardrails section and a related error message specify a maximum of five total polling
attempts. An LLM following the step-by-step instructions is likely to make six calls,
which, when multiplied by the six allowed invocations, results in 36 total `get_thread`
calls, exceeding the intended cap of 30.
Did we get this right? 👍 / 👎 to inform future reviews.
| - If `query-hex` returns `not_found`, try common slug derivations: | ||
| - Lowercase the customer name, replace spaces with hyphens (e.g. "Acme Corp" -> "acme-corp") | ||
| - Try without common suffixes: "inc", "llc", "co", "corp", "ltd" | ||
| - Try the domain name if known (e.g. "acme" from "acme.com") | ||
| - Re-query `query-hex` with each derived slug: "Does a Sentry org with slug '[derived-slug]' exist? Return the slug, plan type, and trial status." |
There was a problem hiding this comment.
Bug: The get-hex-data skill's slug derivation steps suggest more query-hex calls than the guardrail allows, potentially exhausting the invocation budget before the main task is performed.
Severity: HIGH
Suggested Fix
Update the get-hex-data/SKILL.md instructions to align with the guardrails. Either reduce the number of enumerated slug derivation examples or explicitly state that the LLM should only attempt a maximum of three derivations in total, as specified in the guardrail.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/junior-hex/skills/get-hex-data/SKILL.md#L42-L46
Potential issue: The `get-hex-data` skill's instructions for slug derivation are
inconsistent with its invocation limits. The steps enumerate up to seven potential slug
variations to try, instructing the LLM to re-query `query-hex` for each one. This could
lead to eight `query-hex` calls for derivation alone. However, a guardrail limits total
`query-hex` invocations to six per run, with only three allowed for derivation. An LLM
following the steps literally would exhaust its entire invocation budget on derivation,
preventing it from performing its primary function of retrieving usage data.
Did we get this right? 👍 / 👎 to inform future reviews.


Testing
Summary