chore: move file.upload → message.file.upload for Smithery hierarchy score#83
chore: move file.upload → message.file.upload for Smithery hierarchy score#83khaliqgant merged 3 commits intomainfrom
Conversation
Renames file.upload → message.file.upload to eliminate a singleton top-level namespace. Files are uploaded to attach to messages so the grouping is semantically correct. Adds backward-compat alias for the old name. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
khaliqgant
force-pushed
the
chore/file-upload-hierarchy
branch
from
7031ced to
975395a
Compare
Addresses Devin review feedback — the handler now accepts the limit arg (discarded with TODO) and the description clarifies it is reserved. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The inbox.check tool declared a limit input param but the handler and
SDK ignored it. Now the SDK's inbox() accepts { limit } and passes it
as a query param, and the MCP handler forwards it through.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| async inbox(options?: { limit?: number }): Promise<InboxResponse> { | ||
| const params: Record<string, string> = {}; | ||
| if (options?.limit != null) params.limit = String(options.limit); | ||
| return this.client.get('/v1/inbox', params); |
There was a problem hiding this comment.
🟡 Inbox limit parameter is non-functional — server ignores it entirely
The new limit parameter on inbox() in the SDK (packages/sdk-typescript/src/agent.ts:473-476) sends ?limit=N as a query parameter to the server, and the MCP tool message.inbox.check (packages/mcp/src/tools/features.ts:83) advertises it as "Maximum number of inbox items to return". However, the server route at packages/server/src/routes/inbox.ts:14-19 never reads any query parameters — it calls inboxEngine.getInbox(db, workspace.id, agent!.id) with no limit argument. The engine function (packages/server/src/engine/inbox.ts:13) has signature getInbox(db, workspaceId, agentId) with hardcoded LIMIT 20 in its SQL queries. As a result, the limit parameter is silently ignored, misleading LLM agents that use it expecting fewer results.
Prompt for agents
The limit parameter added to the inbox() SDK method (packages/sdk-typescript/src/agent.ts:473-476) and the MCP tool message.inbox.check (packages/mcp/src/tools/features.ts:83-89) is non-functional because the server never reads it. To fix this:
1. In packages/server/src/routes/inbox.ts, read the limit query parameter from the request context (e.g. const limit = parseInt(c.req.query('limit') || '', 10) || undefined) and pass it to inboxEngine.getInbox.
2. In packages/server/src/engine/inbox.ts, add an optional limit parameter to the getInbox function signature and use it to cap the results (e.g. apply it to the mentions and reactions queries instead of hardcoded LIMIT 20).
3. Update openapi.yaml to document the new limit query parameter on GET /v1/inbox, per the AGENTS.md docs hygiene rule.
Alternatively, if the server support is intended for a future PR, remove the limit parameter from the SDK and MCP tool to avoid misleading users.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Preview deployed!
This preview shares the staging database and will be cleaned up when the PR is merged or closed. Run E2E testsnpm run e2e -- https://pr83-api.relaycast.dev --ciOpen observer dashboard |
1 participant
Summary
file.upload→message.file.uploadto eliminate a singleton top-level namespace (8 → 7 top-level namespaces)file.uploadstill resolvesTest plan
🤖 Generated with Claude Code