LLM-Tool-Survey is one README and an assets folder, ordered by a four stage taxonomy

The repository root is a README and an assets folder

The fastest way to understand this project is to read its file listing, which is two entries.

There is a README, and there is an assets folder. There is no source directory, no build configuration, no package manifest, no licence file, and no continuous integration. The repository metadata reports no licence and no detectable primary language, which is consistent: there is nothing here to detect.

So this is a reading list that happens to live on a code hosting platform, and that has consequences worth being clear about. Nothing here can be installed, pinned, or run. There are no releases, so the last commit is the only version marker, and the last push to the main branch is dated 2026-09-09.

It is not a low traffic repository. It has 492 stars and only one open issue, which is roughly what you would expect from a link target people bookmark and return to rather than a place people file problems.

The assets folder exists to hold figures for the README. Everything else is prose, and the prose is a bibliography with a structure imposed on it.

The four stage taxonomy is the argument, not the filing

The table of contents is the survey's thesis expressed as a filing system, and it is worth reading as an argument rather than as an index.

The document splits into why and how. The why side has two parts, the benefit of tools and the benefit of tool learning, and the introduction states that the benefits of tool integration and the benefits of the tool learning paradigm are reviewed from six specific aspects.

The how side is where the partition is sharpest. Four key stages in the tool learning workflow: task planning, tool selection, tool calling, and response generation. Every paper under that heading has to sit at one of those four, which is a constraint on inclusion rather than a description of what exists.

Then two sections that are indexed by the taxonomy rather than living beside it. Benchmarks and evaluation methods are summarised and categorised according to their relevance to different stages, so a benchmark is filed by the stage it measures rather than by the paper that introduced it. That is the more useful half of the survey for anyone building an evaluation, because it lets you ask which stage is under-measured.

The structure closes with challenges and future directions and a section for other resources.

Search engines get eight papers and knowledge graphs get six

The paper list is visible far enough into the document to read its shape, and the shape is finer than the four stages.

Under the benefit of tools sits knowledge acquisition, and that splits into three subcategories by the kind of external resource being reached. Search engines, databases and knowledge graphs, and weather or map.

The search engine category is the largest single group, with eight entries, and it traces the field's own history in order: a 2021 preprint on internet-augmented dialogue, then WebGPT the same year, then a 2022 preprint on few-shot prompting for open-domain question answering, then REPLUG and Toolformer in 2023, then automatic multi-step reasoning with tool use, then ToolCoder, and finally a 2024 conference paper on models self-correcting through tool-interactive critiquing.

The database and knowledge graph category has six. It starts in 2022 with a dialog application model and includes Gorilla, tool embeddings, a question answering dataset, a finite state decoding approach to syntax-error-free tool use, and a middleware paper for language agents.

Weather or map has three, including a study of open source models' tool manipulation ability and a simulated case benchmark of three thousand cases.

A second top level category, expertise enhancement, begins with mathematical tools, where a verifier training paper, the MRKL modular neuro-symbolic architecture, and a chained-thought numerical reasoning paper sit.

Preprint is a category, not a disclaimer

Every entry in the paper list carries a label in the same position, and those labels encode a decision.

The labels are venue names with years. ACL 2022. NeurIPS 2023. ICLR 2024. EMNLP 2024. NeurIPS 2024. And, appearing just as often, Preprint with a year.

Listing preprint as a category alongside a named conference means the list does not filter on peer review. In the search engine group above, five of eight entries are preprints and three are conference papers. In the database and knowledge graph group, the balance tilts the other way.

That is a defensible choice for a survey whose stated purpose includes reducing the fragmentation that makes the field hard to enter, and it also has a cost: the label tells you where a work appeared and when, but a preprint label is not a quality signal in either direction. If you are using this list to pick what to read first, the citation counts and venues are more informative than the presence or absence of the word preprint.

Each entry links out to an arXiv abstract page under a Paper link, so the repository itself stores titles, venues, and identifiers rather than files.

The homepage field points at the paper, not the code

One repository level detail settles how to cite this project.

The homepage field is set to an arXiv abstract identifier rather than to any site of the project's own. There is no documentation site, no blog, and no separate landing page. The paper is the artefact and the repository is the appendix.

The citation block in the README confirms that reading. It is a BibTeX entry for a journal article rather than a preprint citation: the title is the survey title, the journal is Frontiers of Computer Science, published by Springer, at volume 19, number 8, with article number 198343, in 2025.

That metadata is the current status of the work. An earlier README states only that the survey has a preprint, and the current one records that the paper has been accepted to that journal and that the latest version has been released. The eight authors are listed in full, which for a survey paper is the more useful detail, since a survey's provenance is the set of people who chose the taxonomy.

One practical consequence: because there is no licence file, the repository has no explicit reuse grant. The paper is under the journal's terms. Anyone wanting to reuse the taxonomy should cite the article rather than copy the README.

The workflow figure is the one asset the README cannot show

The introduction refers to a single figure and the document does not carry it.

The heading is the overall workflow for tool learning with large language models, which is the same four stage sequence the how section is built on, presented as a picture. In the README the heading is followed by an empty alignment container and nothing else.

So the figure lives in the assets folder, referenced as an image, or it does not exist yet. Either way the README as rendered from this repository has a caption and no diagram, which is a poor way to introduce the central concept of the survey since the diagram is what a newcomer would use to place a paper in the taxonomy.

The same pattern applies to the table of contents. It is generated with emoji in the heading text and emoji in the anchor links, which is a deliberate stylistic choice rather than a defect, but it does mean the anchor targets depend on how a renderer handles those characters and can break in some readers.

For a document meant to be read as an index rather than a paper, navigation robustness is not an aesthetic concern. The paper version will have the figure rendered properly; the repository is the degraded copy.

The Chinese coverage was written elsewhere and only linked

The project has an explicit note about language coverage, and it points outward rather than inward.

Two Chinese-language introductions exist, one brief and one long form, and both were produced by outside groups rather than by the survey authors. Two projects are credited by name, one for the shorter treatment and one for the longer one, and the README thanks them for the help and links to both as hosted articles.

There are no other language versions in the repository. The main README is English, and there is no directory holding translations, no build step producing them, and no contribution path described for adding one. The contribution guidance is a single line inviting issues and pull requests, without a process document.

So the distribution of the survey's ideas has been widened, but the widening sits outside the project's own maintenance. If the translated version and the English version disagree, or if the English one gains sections the translations never receive, there is no mechanism in the repository that would catch it.

This is a normal outcome for academic work and not a criticism of the authors. It is worth knowing because a reader arriving through a Chinese introduction is reading a derivative of the taxonomy rather than the taxonomy itself, and the four stage split may be described differently there.

A paper list maintained like a repository

The final thing worth saying is about what maintaining this repository actually involves, because it explains the shape of the artefact.

The work is not code. It is deciding where new tool learning papers belong in a taxonomy that was fixed when the survey was written, and that is a harder editorial problem than maintaining a library. A new paper that spans two of the four stages forces a decision about the partition itself, and there is no process described for making that decision beyond opening an issue.

The scale is legible from the citation count in the listing. Under knowledge acquisition alone there are already seventeen entries across three subcategories, and the expertise enhancement branch begins with mathematical tools and clearly continues. The four stage section and the benchmarks section follow, and both are places where the field moves quickly.

The staleness risk is therefore asymmetric. A code repository goes stale by not building; this one goes stale by not being reorganised. A taxonomy that was defensible for the 2024 literature can be wrong for the 2026 literature while every entry in it remains individually correct and every link still resolving.

For a reader, the practical advice is to use the four stage split as a starting vocabulary and to check the paper rather than the list for anything you intend to build on.

Editorial conclusion

LLM-Tool-Survey suits someone entering tool learning research who needs a map rather than a toolkit, since the four stage taxonomy, task planning, tool selection, tool calling, and response generation, is a partition you can reuse whether or not you read the paper. It does not suit anyone looking for code, an evaluation harness, or a maintained benchmark, because there is none in the repository. Three things to check before you rely on it. The preprint label is used as a first class category alongside named conference venues, so a listing tells you where a work was published but not whether it was peer reviewed, and you have to read that yourself. The two Chinese introductions were written by other groups and linked from outside the repository, so the multilingual coverage is not maintained here. And there is no licence file and no tagged release, so the last push on 2026-09-09 is the only version marker and you should cite the paper rather than the repository.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. quchangle1/LLM-Tool-Survey on GitHub
4. README