Enhancement: Exact counts without paging rows - #464
Merged
Conversation
twapi-go-sdk v1.21.5 exposes `meta.page.count` on v3 list endpoints. Surface it
two ways: `count_only` on the 27 list tools whose endpoint reports a count, and
`count_tasks`, `count_projects`, `count_milestones`, `count_timelogs` for a model
reasoning from "how many" rather than from a list call. Both answer `{"count": N}`
with no rows, and the count tools are derived from their list tool with
`count_only` injected, so the filters stay defined once.
`helpers.NewCountToolResult` rewires the request by reflection — page 1, one row,
`skipCounts=false`, no sideloads, fieldsets or cursor — so a list tool needs one
branch and a future one needs no count code. Pinning the exact count is
correctness, not economy: `skipCounts=true` keeps `count` in the response but
replaces the total with the lower bound `(page * pageSize) + 1`, which is 2 at
`pageSize=1`, and the SDK's `ResolveCount` only clears that for callers decoding
the typed response — which the list tools deliberately do not.
The tests assert on the outgoing query, because the mocks reply with the same
canned body whether an exact count was asked for or not. Tool definitions grow 8%.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
rafaeljusto
force-pushed
the
feature/tool-counts
branch
from
August 17, 2026 21:53
733c5d7 to
ced6c0e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
twapi-go-sdk v1.21.5 exposes
meta.page.counton v3 list endpoints. Surface it in two ways:count_onlyon the 27 list tools whose endpoints report a count, andcount_tasks,count_projects,count_milestones,count_timelogsfor a model reasoning from "how many" rather than from a list call. Both answer{"count": N}with no rows, and the count tools are derived from their list tool withcount_onlyinjected, so the filters stay defined once.helpers.NewCountToolResultrewires the request by reflection — page 1, one row,skipCounts=false, no sideloads, fieldsets or cursor — so a list tool needs one branch and a future one needs no count code. Pinning the exact count is correctness, not economy:skipCounts=truekeepscountin the response but replaces the total with the lower bound(page * pageSize) + 1, which is 2 atpageSize=1, and the SDK'sResolveCountonly clears that for callers decoding the typed response — which the list tools deliberately do not.The tests assert on the outgoing query, because the mocks reply with the same canned body whether an exact count was asked for or not. Tool definitions grow by 8%.
Type of Change
Testing
go test -v ./...)Checklist