should mcp servers return partial results or just fail fast
building an mcp server for database queries and can't decide: if a query times out after 10s, should i return partial results + error flag, or just return an error and make the agent retry? partial results feel better for ux but harder to handle in the agent prompt. full failure is cleaner but wastes the work. what are people doing?
partial results imo. if the mcp server can return something useful it should - the agent can always retry if it needs more. what's your use case?
use case is an mcp server that queries an api with pagination - sometimes the first page has what the agent needs, sometimes it doesn't. wasn't sure if i should return page 1 and let the agent ask for more, or just fail if i can't get everything
fail fast unless the partial result is actually useful. we had an agent that would get page 1, hallucinate that it found the answer, and never paginate. better to return an error and force the agent to handle it explicitly
partial results make sense imo but you need to tell the agent explicitly that it's partial. we return {"data": [...], "has_more": true, "next_page": 2} and the agent learns to paginate. could be wrong but i think failing fast confuses the model more
partial results with has_more is the right pattern imo. we do the same thing and also include a "query" field with the original query so the agent can refine it if needed. works pretty well
partial results make sense for expensive operations or stuff that can timeout. is your mcp server doing queries that might hit a limit?
+1 on partial results. we built an mcp server for a postgres db and return the first 50 rows with a has_more flag. works great for most queries and the agent has learned to refine when it needs more. the key is making the has_more flag really obvious in the response schema and mentioning it in the tool description
partial results with has_more makes sense for postgres yeah. we do same pattern for elasticsearch - return 25 results max with a cursor token, agent learns to paginate when it needs more. works like 85% of the time
partial results with has_more is fine but you need to be really explicit in the tool description about what partial means. we tried this with a logs server and the agent would get page 1, decide it found nothing, and give up. added "ALWAYS check has_more before concluding" and it got better
partial results are fine if the agent knows to paginate, but if it doesn't then you're just training it to assume page 1 is complete. what's your actual retry rate when has_more is true
partial results with has_more is the right pattern imo but you need to log when the agent ignores has_more and assumes page 1 is complete. we added logging for this and found the agent ignores pagination like 40% of the time, which is... not great
what's the logging setup for tracking when agents ignore has_more
ok so we block retries with identical args after the first failure. if the agent can't figure out what to change it's not gonna magically work on attempt 3, it's just wasting tokens
we log every ignored has_more with the full context (thread id, tool name, result count, whether the agent called the tool again). turns out the agent ignores pagination like 30% of the time and just assumes page 1 is everything 😅