search_errors / search_logs / search_traces silently ignore an unknown `projectSlugOrId` argument

Open
  • Is something wrong?
#2,231 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
api

Research direction

Start by comparing the input schemas of search_issues and search_errors, which name the project argument differently (projectSlugOrId vs projectSlug), and check how the other search tools (search_logs, search_traces, and the rest) declare theirs. Reproduce by calling search_errors with projectSlugOrId and confirming the result link has no project parameter. Done when an unknown project key is rejected or the same argument name works on every search tool, and executedSearch shows the applied project scope. The maintainers still need to choose between the two expected fixes.

Written by the indexing model from the issue text.

Description

search_issues takes its project as projectSlugOrId, and its own tool description shows that name in its examples and hints. The other search leaves (search_errors, search_logs, search_traces, search_metrics, search_profiles, search_replays) take projectSlug instead. An agent that has just used search_issues often reuses projectSlugOrId on search_errors.

The input schemas don't set additionalProperties: false, so the unknown key is accepted and dropped without any error or warning. The search then runs across the whole organization, even though the caller asked for one project.

Reproduction

Use an organization example-org with projects php-app (ID 123) and go-service:

search_errors(
  organizationSlug="example-org",
  projectSlugOrId="php-app",
  query="errors in the last 24 hours grouped by error type with counts"
)
  • The call succeeds.
  • The result link has no project parameter: ...&query=&field=error.type&field=count%28%29&statsPeriod=24h...
  • The rows include Go error types (*fmt.wrapError, context.deadlineExceededError) from go-service.

The same call with projectSlug="php-app" scopes correctly: the link has project=123, and only php-app errors come back.

executedSearch.query is "" in both responses, because the project filter is a separate request parameter. The response gives the caller no sign that the filter was dropped.

Expected

Either of these would prevent the silent cross-project result:

  1. Reject unknown arguments (strict input schemas, or a validation error that names the unknown key and the expected one).
  2. Accept the same project argument name on every search tool (for example, accept projectSlugOrId as an alias of projectSlug, or the other way round).

It would also help to show the applied project scope in executedSearch, so callers can check it.

Environment

Remote MCP at https://mcp.sentry.dev/mcp, called through our MCP gateway, which forwards tool arguments unchanged.

Dominant language
TypeScript
Stars
961
Forks
179
Avg merge
15h 33m
Merged PRs (30d)
476

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from getsentry/toolkit

All issues in getsentry/toolkit

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.