{ "schema_version": 1, "builder_plan": { "scenario": "An assistant chooses the wrong API or sends arguments your product cannot use.", "change": "Apply the proposed tool-selection or argument-generation change in a sandbox.", "baseline": "Your current agent with the same tool schemas and task budget.", "steps": [ "Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.", "Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.", "Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.", "Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test." ], "measure": "Correct completed actions, invalid calls, retries, latency, and cost per completed task.", "decision": "Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation." }, "builder_review": null, "arxiv_id": "2609.24161", "title": "MCP-GRANITE Benchmark: GRANularity Interface TEsting for MCP-Based LLM Agents", "summary": "It replaces ad hoc tool decomposition (either fine-grained primitive tools or a single monolithic tool) with a deliberately chosen intermediate granularity, around four tools per interface, in MCP-based agent designs. It costs no additional memory or serving infrastructure, since it is an interface design change, but it requires re-specifying tool schemas, argument contracts, and possibly re-validating prompts across the tool suite. It can fail when the optimal granularity is domain- or workload-specific, since the finding derives from 81 edge/IoT scenarios and may not transfer to general enterprise toolsets, and coarse interfaces can still constrain agents on unanticipated task decompositions.", "rationale": "The result is a zero-cost design guideline that directly benefits small local models, letting constrained teams recover task-completion and argument-accuracy losses without larger hardware.", "technique": "Tool-interface granularity tuning for MCP agents", "family": "uso_de_ferramenta", "recommendation": "adotar", "published": "2026-09-21", "as_of": "2026-10-18", "editorial_status": "indexed", "source_url": "https://arxiv.org/abs/2609.24161", "independent_implementations": 0, "total_implementations": 0, "stars": 0, "citations": 0, "claims": [ { "claim_id": "claim-01", "statement": "It replaces ad hoc tool decomposition (either fine-grained primitive tools or a single monolithic tool) with a deliberately chosen intermediate granularity, around four tools per interface, in MCP-based agent designs. It costs no additional memory or serving infrastructure, since it is an interface design change, but it requires re-specifying tool schemas, argument contracts, and possibly re-validating prompts across the tool suite. It can fail when the optimal granularity is domain- or workload-specific, since the finding derives from 81 edge/IoT scenarios and may not transfer to general enterprise toolsets, and coarse interfaces can still constrain agents on unanticipated task decompositions.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2609.24161", "source_page": null, "source_excerpt": "" }, { "claim_id": "claim-02", "statement": "A 4-tool interface improves task completion by 16.4% over fine-grained primitives and 33.6% over a single monolithic tool, while nearly doubling argument accuracy; a 3.2B model at the optimal granularity outperforms a 20.9B model at a mismatched one.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2609.24161", "source_page": null, "source_excerpt": "" } ], "exposure_map": [ { "dimension": "quality", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compute", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "latency", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "operations", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compatibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "security", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "data_and_training", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "reproducibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" } ], "risks": [], "minimum_test": [], "open_questions": [], "independent_tests": [], "lab_reproductions": [], "report_available": false, "validation_tier": "unknown", "evidence_tier": "unknown", "infrastructure_basis": "unknown", "equations": [], "equations_status": "not_fetched", "core_kind": "", "equations_fetched_at": "", "equations_source_url": "", "equations_source_sha256": "", "exposures_reviewed_at": "", "exposures_source_sha256": "" }