connect_scores_batchRetrieve reputation scores for multiple users or linked accounts in one request, returning one result per user and optional filters to set passedFilter.
Batch scores for linked accounts or Connect usernames. One result per request user. Optional filter sets passedFilter (quidli 0–100, neynar/lens 0–1, ethos 0–2800).
| Name | Required | Description | Default |
|---|---|---|---|
| users | Yes | Users to fetch scores for | |
| filter | No |
Changes observed during successful MCP inspections.
v0.5.2Input schema / properties / filter / properties / minScore / descriptionAdded value: +"quidli_score: 0–100; neynar/lens: 0–1; ethos_twitter/wallet: 0–2800"v0.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: result cardinality ('one result per request user') and what the optional filter actually accomplishes ('sets passedFilter'), which is not derivable from the annotations. It stops short of describing failure behavior for unresolvable users.
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?
Three short sentences, no filler, and the core capability is front-loaded ahead of the optional filter detail. The parenthetical score ranges are the only element that arguably duplicates the schema and could be dropped.
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?
With no output schema and a nested two-param input, the description carries more burden than it meets. It hints at output shape via 'one result per request user' and explains the filter's effect, but omits what a score result contains, batch-size limits, and how partial failures or unknown identifiers are handled.
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 50% and the enum/range details for minScore are already in the schema, so the description's restatement of the 0–100 / 0–1 / 0–2800 bands is largely redundant. Its one genuine addition is explaining that the filter produces a passedFilter flag, but it says nothing about the users array's id/type/username shape or how 'linked accounts vs Connect usernames' maps onto the type enum.
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?
States a specific verb and resource (batch scores) plus the scope ('linked accounts or Connect usernames') and cardinality ('one result per request user'). The word 'Batch' in the name and 'one result per request user' imply it handles multiple identities, but the description never names the singular siblings connect_scores_by_account / connect_scores_by_username to make the routing decision explicit.
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?
Usage is only implied: the batching semantics suggest this is the multi-user path, but there is no explicit 'use this when you have many users, use connect_scores_by_username for one' guidance. No prerequisites, no limits on batch size, no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.