The 100 Best AI Agent Tools in 2026

An agent without tools is a text generator with opinions. Tools are what let a model read a page it has never seen, write a row to a database, move money, or restart a container. Everything else in an agent stack exists to decide which tool to call and what to do with the result.

This is a reference list of 100 tools that agents call directly in production, grouped by the capability domain they serve. Every entry has three lines: what the tool does, what an agent specifically uses it for, and the constraint that will bite you. The constraint line is the one worth reading twice, because tool selection failures are almost never about features. They are about rate limits, auth models, latency, and output shape.

No rankings by popularity, no adoption numbers, no invented benchmarks. The order inside each group is grouping-by-affinity, not merit.

---

Tool, skill, or framework: three different things

These three words get used interchangeably, and the confusion produces bad architecture. The distinction is mechanical.

A tool is a callable capability with a typed interface and an effect outside the model. It takes structured arguments, performs I/O against a real system, and returns structured output. send_email(to, subject, body) is a tool. query_warehouse(sql) is a tool. The defining property is that a tool does something the model cannot do by thinking harder. It reaches outside the context window. Tools are the unit of action.

A skill is packaged procedural knowledge that tells the model how and when to use tools. A skill has no I/O of its own. It is instructions, decision criteria, worked examples, and sometimes bundled reference material, loaded into context when a task matches it. "How to triage an incident" is a skill; it orchestrates calls to your logging tool, your paging tool, and your ticket tool, but it cannot page anyone by itself. Skills are the unit of knowledge. If you are building those, the companion piece is the 100 best AI agent skills.

A framework is the runtime that hosts the loop. It manages the conversation state, decides when to call the model, dispatches tool calls, handles retries and timeouts, enforces budgets, and persists memory. LangGraph, the OpenAI Agents SDK, and CrewAI are frameworks. A framework is the unit of orchestration, and it is the layer you swap least often. We cover that layer separately in best AI agent frameworks.

The relationship is strict and one-directional:

A framework loads a skill, which instructs the model to call a tool.

Two practical consequences follow.

First, do not turn a skill into a tool. If your "tool" takes a paragraph of natural language and returns a paragraph of natural language, it is a prompt wearing a schema. Tools should have narrow arguments and deterministic-shaped returns so the model can reason about the result instead of re-parsing prose.

Second, do not turn a tool into a framework. A tool that internally runs its own planning loop is invisible to the parent agent's budget, tracing, and error handling. When it fails, you get one opaque error instead of a call graph. Keep the loop in one place.

MCP servers sit at an angle to all three: they are a transport and packaging standard for exposing tools (and prompts and resources) to any compatible client. An MCP server is not a fourth category, it is how a tool gets delivered. See the 100 best MCP servers for that catalogue. If you want these capabilities wired up without writing connector code, start at /integrations/.

---

How to read each entry

• Function — what the service does, independent of agents.
• Agent use — the specific call pattern an agent makes against it.
• Constraint — the property that determines whether it works inside an autonomous loop.

Links go to first-party domains only. Pricing, quotas, and model availability change; check the vendor before you commit.

---

Web and browser control (1–12)

Agents that operate the open web need three separable things: a driver that can control a page, infrastructure to run that driver somewhere durable, and an extraction layer that turns HTML into something a model can read without burning the context window.

1. AGNT — https://agnt.gg
Function: a local-first agent operating system with agents, visual workflows, long-running goals, memory, skills, plugins, MCP, evaluations, traces, provider auth, and a local API.
Agent use: the control plane that connects models to tools and turns one-off tool calls into durable, inspectable work with approvals, retries, schedules, and reusable workflows.
Constraint: AGNT is our product and uses a custom source-available license. It is built for trusted local workspaces and self-hosting, not public multi-tenant isolation. Download AGNT or inspect the repository.

2. Playwright — https://playwright.dev
Function: cross-browser automation library driving Chromium, Firefox, and WebKit through a single API.
Agent use: the default driver for agents that must click, type, upload, and wait for real application state rather than parse static HTML.
Constraint: it exposes the full DOM, and the full DOM is far larger than a useful context window. You need an accessibility-tree or selector-filtered projection before the model sees anything.

3. Puppeteer — https://pptr.dev
Function: Node library controlling Chrome and Chromium over the DevTools Protocol.
Agent use: screenshot capture, PDF rendering, and low-level page instrumentation where you want direct CDP access rather than an abstraction.
Constraint: Chromium-family only. If your target renders differently in WebKit, this will not surface it.

4. Selenium WebDriver — https://www.selenium.dev
Function: the W3C-standard browser automation protocol with bindings across most major languages.
Agent use: driving legacy internal applications and enterprise test grids that already standardised on WebDriver.
Constraint: the synchronous, polling-oriented API produces slower loops than CDP-based drivers, which matters when an agent takes dozens of actions per task.

5. Browserbase — https://www.browserbase.com
Function: hosted, managed browser sessions with session recording and remote control.
Agent use: giving an agent a persistent browser it does not have to boot, patch, or clean up between runs.
Constraint: every action crosses a network boundary, so per-step latency is higher than a local browser. Batch interactions where the page allows it.

6. Browserless — https://www.browserless.io
Function: headless Chrome as a service, addressable over WebSocket and REST.
Agent use: a drop-in remote endpoint for existing Puppeteer or Playwright code, so agent workers stay stateless.
Constraint: concurrency is the billing and scaling axis. A fan-out agent that opens many pages at once will hit the session ceiling before it hits any rate limit.

7. Steel — https://steel.dev
Function: open-source browser infrastructure purpose-built for agent sessions, with proxy and session management.
Agent use: running long-lived authenticated sessions where cookies and local storage must survive across agent turns.
Constraint: session persistence means credential persistence. Treat every stored session as a live secret with an expiry policy.

8. Firecrawl — https://www.firecrawl.dev
Function: crawls and scrapes sites, returning clean Markdown or structured JSON instead of raw HTML.
Agent use: the extraction step after discovery, converting a URL list into model-readable text without a custom parser per site.
Constraint: JavaScript-heavy and aggressively bot-protected sites still fail or degrade. Build a fallback path rather than assuming extraction always succeeds.

9. Apify — https://apify.com
Function: a platform of prebuilt scrapers ("Actors") plus a runtime for custom ones, with storage and scheduling.
Agent use: calling an existing, maintained scraper for a well-known target instead of writing and maintaining selectors yourself.
Constraint: Actor quality varies by author, and a scraper silently returning fewer fields after a site redesign is a data-integrity failure, not an error. Validate the output schema on every run.

10. Bright Data — https://brightdata.com
Function: proxy networks and web-data collection infrastructure at scale.
Agent use: retrieval from sources that block datacenter IP ranges, and geo-specific fetches where the result varies by region.
Constraint: proxy use has legal and terms-of-service implications that vary by target and jurisdiction. This is a policy decision before it is a technical one.

11. ScrapingBee — https://www.scrapingbee.com
Function: a single API endpoint that handles proxy rotation, headless rendering, and retries.
Agent use: a low-integration-cost fetch tool for agents that need one page at a time and no crawl state.
Constraint: the API abstracts away failure modes, so when extraction is wrong you have limited visibility into why. Log the raw response, not just the parsed result.

12. Zyte — https://www.zyte.com
Function: web scraping API and infrastructure with automatic extraction for common page types.
Agent use: structured extraction of recognisable entities such as articles and product pages without per-site rules.
Constraint: automatic extraction works on page types it recognises. Novel layouts fall back to generic text, and the agent needs to detect that drop in fidelity.

13. Oxylabs — https://oxylabs.io
Function: proxy infrastructure and scraper APIs for large-scale collection.
Agent use: sustained high-volume retrieval jobs where a single-endpoint scraper would rate-limit.
Constraint: capacity is provisioned, not elastic on demand. Bursty agent workloads need to be smoothed or they will queue.

---

Search and retrieval (13–24)

Search is the tool agents call most and reason about worst. The failure mode is not "no results" — it is plausible, well-formatted, wrong results that the model then treats as ground truth. Prefer search tools that return source URLs and enough content to verify a claim, and always separate the search step from the read step.

14. Exa — https://exa.ai
Function: a search API built for retrieval by meaning, with content retrieval alongside results.
Agent use: finding pages that match a described concept when the agent does not know the right keywords.
Constraint: semantic matching returns things that are topically near rather than factually relevant. Verification against the fetched page is mandatory.

15. Tavily — https://www.tavily.com
Function: a search API designed for LLM consumption, returning condensed results and optional direct answers.
Agent use: the first hop in a research loop where the agent needs candidate sources fast and cheaply.
Constraint: the condensed answer field is a summary of retrieved snippets. Cite the underlying URLs, never the summary.

16. Brave Search API — https://brave.com/search/api/
Function: programmatic access to an independent web index.
Agent use: a search backend that is not a wrapper around another engine, useful for index diversity.
Constraint: independent index means different coverage. For long-tail and regional queries, results will differ from what you see in a mainstream engine.

17. SerpApi — https://serpapi.com
Function: structured, parsed results from search engine result pages.
Agent use: agents that need the actual ranked SERP — including features like knowledge panels — rather than a re-ranked API index.
Constraint: SERP structure changes without warning, and per-query cost makes broad exploratory loops expensive. Cap query count per task.

18. Perplexity API — https://docs.perplexity.ai
Function: search-grounded model responses with citations.
Agent use: one call that both searches and synthesises, for questions where the agent needs an answer plus sources rather than a link list.
Constraint: synthesis happens outside your control, so you inherit its retrieval and summarisation choices. Unsuitable when you need the raw source set.

19. Kagi — https://kagi.com
Function: an ad-free search product with programmatic access.
Agent use: retrieval where result quality matters more than cost per query, such as expert research tasks.
Constraint: it is a paid-per-query model with no free tier to absorb runaway loops. Budget enforcement belongs in the framework, not the tool.

20. Algolia — https://www.algolia.com
Function: hosted search and discovery over your own indexed records.
Agent use: letting an agent search a product catalogue or documentation corpus with the same relevance the end user gets.
Constraint: it searches what you indexed. Index freshness becomes an agent-correctness problem, not just a UX problem.

21. Elasticsearch — https://www.elastic.co
Function: a distributed search and analytics engine supporting full-text, filtering, and vector search.
Agent use: retrieval across large internal corpora where the agent needs filters and aggregations, not just similarity.
Constraint: relevance is a tuning discipline. Default configuration gives you a working query surface, not good answers.

22. Typesense — https://typesense.org
Function: an open-source, typo-tolerant search engine with a simple API.
Agent use: fast, self-hostable retrieval for agents operating on data that cannot leave your infrastructure.
Constraint: it is designed to hold the working set in memory. Corpus size is bounded by RAM, which shapes what you can index.

23. Meilisearch — https://www.meilisearch.com
Function: an open-source search engine focused on fast setup and instant results.
Agent use: a low-operational-cost internal search tool for document and knowledge-base lookups.
Constraint: the same memory-resident design trade-off applies, and very large indexes are not its target case.

24. Azure AI Search — https://azure.microsoft.com/products/ai-services/ai-search
Function: managed search with vector, keyword, and hybrid retrieval plus document enrichment.
Agent use: enterprise retrieval where the corpus already lives in Azure and access control must follow existing identities.
Constraint: security trimming has to be configured explicitly. Without it, an agent can retrieve documents the requesting user could not open directly.

25. Google Programmable Search Engine — https://programmablesearchengine.google.com
Function: a scoped search engine over sites you specify.
Agent use: restricting agent retrieval to an allowlist of trusted domains.
Constraint: daily query quotas on the free tier are low enough that a single misbehaving loop can exhaust them.

---

Data and knowledge (25–38)

Two distinct tool classes live here, and mixing them up causes real damage. Transactional stores answer questions about current state and accept writes. Vector stores answer "what is similar to this" and should almost never be the system of record. An agent that writes its conclusions back into the same vector store it reads from will, over enough cycles, reinforce its own errors.

26. PostgreSQL — https://www.postgresql.org
Function: a relational database with strong transactional guarantees and extension support including vector types.
Agent use: the system of record an agent queries for facts and writes to under explicit constraints.
Constraint: never hand an agent a superuser connection. Bind it to a role with row-level security and a statement timeout, and expose parameterised queries rather than raw SQL where you can.

27. Supabase — https://supabase.com
Function: managed Postgres with auth, storage, realtime, and auto-generated APIs.
Agent use: giving an agent a data tool where row-level security already encodes who may read what.
Constraint: the service key bypasses row-level security entirely. If an agent ever holds it, your policies are decoration.

28. Neon — https://neon.com
Function: serverless Postgres with branching and scale-to-zero compute.
Agent use: giving an agent a disposable database branch so destructive operations are contained and reversible.
Constraint: cold starts add latency to the first query after idle, which shows up as a mysteriously slow first tool call.

29. Snowflake — https://www.snowflake.com
Function: a cloud data platform for warehousing and analytics.
Agent use: analytical questions over enterprise data that no operational database can answer in one query.
Constraint: compute is billed while a warehouse runs. An agent writing unbounded scans is a cost incident waiting to happen — enforce query timeouts and result limits.

30. Databricks — https://www.databricks.com
Function: a lakehouse platform unifying data engineering, analytics, and ML workloads.
Agent use: agents that need to run computation next to large datasets rather than move data to the agent.
Constraint: job startup latency is measured in tens of seconds. Treat these as asynchronous tools, not request-response calls.

31. Google BigQuery — https://cloud.google.com/bigquery
Function: a serverless analytics warehouse queried with SQL.
Agent use: fast aggregate answers over very large tables without provisioning infrastructure.
Constraint: billing is driven by bytes scanned. Require partition filters and set maximum-bytes-billed on every agent-issued query.

32. DuckDB — https://duckdb.org
Function: an in-process analytical database that queries local files and object storage directly.
Agent use: letting an agent analyse a CSV or Parquet file inside a sandbox with no database server at all.
Constraint: single-process by design. It is an analysis tool, not a shared backend for concurrent agents.

33. ClickHouse — https://clickhouse.com
Function: a columnar database for high-speed analytical queries over large event data.
Agent use: log, metric, and event investigation where the agent needs to slice billions of rows interactively.
Constraint: it rewards append-only, denormalised schemas. Agents that expect relational joins and frequent updates will write slow queries.

34. Pinecone — https://www.pinecone.io
Function: a managed vector database for similarity search.
Agent use: long-term semantic memory and document retrieval keyed by embedding.
Constraint: results are ranked by similarity, never by truth. Always carry source identifiers through to the answer so claims can be traced back.

35. Weaviate — https://weaviate.io
Function: an open-source vector database with hybrid search and a schema model.
Agent use: retrieval that combines semantic similarity with hard metadata filters such as tenant or date.
Constraint: the schema is real and migrations are real work. Changing embedding models generally means re-indexing the corpus.

36. Qdrant — https://qdrant.tech
Function: an open-source vector search engine with rich payload filtering.
Agent use: self-hosted agent memory where filter conditions must be enforced at query time, not after retrieval.
Constraint: high-dimensional indexes are memory-hungry. Capacity planning is a function of vector count times dimensions, and it does not degrade gracefully.

37. Chroma — https://www.trychroma.com
Function: an embedding database designed for straightforward local and application-embedded use.
Agent use: prototyping retrieval and running small per-user memory stores.
Constraint: it is optimised for developer ergonomics at moderate scale. Plan the migration path before the corpus grows.

38. Redis — https://redis.io
Function: an in-memory data store used for caching, queues, and ephemeral state, with vector search support.
Agent use: session state, tool-result caching, deduplication keys, and distributed locks that stop two agents doing the same job twice.
Constraint: memory-resident data needs an explicit eviction and persistence policy, or agent state disappears on restart.

39. Neo4j — https://neo4j.com
Function: a graph database with a declarative query language for relationship traversal.
Agent use: questions about connections — ownership chains, dependency paths, entity relationships — that are painful in SQL and impossible in a vector store.
Constraint: the model must generate correct traversal queries, and query languages outside the SQL mainstream produce more generation errors. Validate before execution.

---

Coding and execution (39–50)

Execution tools are the highest-leverage and highest-risk category. An agent that can run code can do anything the process can do. Every entry here assumes the answer to "should this run with production credentials" is no.

40. GitHub — https://github.com
Function: hosted Git with pull requests, issues, actions, and a comprehensive API.
Agent use: reading repository state, opening branches and pull requests, commenting on reviews, and reacting to CI results.
Constraint: give agents fine-grained tokens scoped to specific repositories, and require human approval on merge. An agent with write access to a default branch is an incident generator.

41. GitLab — https://about.gitlab.com
Function: an integrated DevOps platform covering source control, CI/CD, and issue tracking.
Agent use: pipeline-aware agents that read job logs, diagnose failures, and propose fixes as merge requests.
Constraint: project and group access tokens inherit broad permissions by default. Scope deliberately.

42. E2B — https://e2b.dev
Function: isolated cloud sandboxes purpose-built for running AI-generated code.
Agent use: executing untrusted code, installing packages, and inspecting outputs without touching your infrastructure.
Constraint: sandboxes are ephemeral. Anything the agent must keep has to be written out before the session ends.

43. Modal — https://modal.com
Function: serverless compute for Python workloads including GPU jobs.
Agent use: offloading heavy computation — transforms, model inference, batch processing — from the agent loop.
Constraint: container cold starts are visible in latency. Warm pools cost money to keep ready.

44. Daytona — https://www.daytona.io
Function: infrastructure for provisioning isolated development environments and sandboxes.
Agent use: giving a coding agent a full, reproducible workspace with the repository already checked out.
Constraint: environment definitions must be kept current with the project's real toolchain, or the agent debugs the environment instead of the code.

45. Docker — https://www.docker.com
Function: container build and runtime tooling.
Agent use: reproducible execution environments and a hard boundary around anything the agent runs.
Constraint: a container is isolation, not a security boundary against a determined escape. Mounting the Docker socket into an agent-accessible container is equivalent to granting host root.

46. Jupyter — https://jupyter.org
Function: an interactive computing environment with a documented kernel messaging protocol.
Agent use: stateful, iterative analysis where the agent builds on variables from prior cells rather than re-running everything.
Constraint: persistent kernel state means errors persist too. Agents need an explicit restart action when state becomes incoherent.

47. Sentry — https://sentry.io
Function: error monitoring and performance tracing with grouped issues and stack traces.
Agent use: pulling the actual stack trace, breadcrumbs, and affected release for a failure the agent is asked to fix.
Constraint: payloads can contain user data and secrets captured from request context. Scrub before an agent reads them.

48. Linear — https://linear.app
Function: issue tracking and project management with a well-specified GraphQL API.
Agent use: creating, updating, and triaging issues so agent work is visible in the same queue as human work.
Constraint: GraphQL mutations are strict about required fields and relationships. Expose narrow wrapper tools rather than letting the model compose arbitrary mutations.

49. Jira — https://www.atlassian.com/software/jira
Function: enterprise issue and workflow tracking with configurable schemas.
Agent use: interacting with the ticket system of record where compliance requires an audit trail for every change.
Constraint: custom fields and workflow transitions differ per instance. There is no portable agent integration; each deployment needs its own field mapping.

50. Vercel — https://vercel.com
Function: a deployment and hosting platform for frontend and serverless workloads.
Agent use: creating preview deployments so an agent's change can be verified as a running artifact, not just a diff.
Constraint: preview deployments are publicly reachable unless protection is configured. Agent-created previews of internal work need protection on by default.

51. Replit — https://replit.com
Function: a browser-based development and hosting environment.
Agent use: spinning up a runnable project quickly for prototypes and demonstrations the agent produces.
Constraint: it is built for iteration speed rather than production isolation. Do not use it as a sandbox for untrusted code.

---

Communication (51–62)

Communication tools are where agents become externally visible. They share one property that distinguishes them from every other category: their side effects cannot be undone. A wrong database write can be corrected. A wrong email has been read.

52. Slack — https://slack.com
Function: team messaging with a full platform API, events, and interactive components.
Agent use: receiving requests in channels and threads, posting results, and asking for approval with interactive buttons.
Constraint: OAuth scopes are granular and the difference between reading one channel and reading the workspace is one scope. Request the minimum and re-audit after every feature addition.

53. Microsoft Teams — https://www.microsoft.com/microsoft-teams/group-chat-software
Function: enterprise collaboration with messaging, meetings, and a bot framework.
Agent use: surfacing agents inside the tenant where enterprise identity and compliance policy already apply.
Constraint: bot registration and tenant admin consent are prerequisites, so deployment is an IT process rather than a developer decision.

54. Discord — https://discord.com
Function: community messaging with a documented bot and interactions API.
Agent use: community-facing agents that respond to slash commands and moderate content.
Constraint: interaction responses must be acknowledged within a short window. Slow agents need a deferred response pattern or the interaction visibly fails.

55. Gmail API — https://developers.google.com/gmail/api
Function: programmatic access to Gmail messages, threads, labels, and drafts.
Agent use: triaging an inbox, extracting structured data from messages, and preparing drafts for review.
Constraint: send scopes are irreversible in effect and trigger a stricter Google verification process. Default agents to draft-only and require a human to send.

56. Microsoft Graph — https://learn.microsoft.com/graph/
Function: a unified API across Microsoft 365 including Outlook mail, calendar, files, and directory.
Agent use: one credential surface for an agent that spans mail, calendar, and documents in a tenant.
Constraint: application permissions apply tenant-wide with no user scoping. Prefer delegated permissions so the agent inherits the requesting user's access.

57. Resend — https://resend.com
Function: a transactional email API oriented toward developers.
Agent use: sending notifications and reports generated by agent runs.
Constraint: deliverability depends on domain authentication you configure. An agent that sends from an unauthenticated domain is writing to the spam folder.

58. SendGrid — https://sendgrid.com
Function: transactional and marketing email infrastructure with event webhooks.
Agent use: high-volume sends where the agent needs delivery, bounce, and open events fed back into its state.
Constraint: sender reputation is shared and slow to repair. One agent loop that sends duplicates can degrade delivery for everything on that domain.

59. Twilio — https://www.twilio.com
Function: programmable SMS, voice, and messaging APIs.
Agent use: notifications, verification codes, and voice interactions that reach a user outside any app.
Constraint: messaging is regulated, requires registration in several jurisdictions, and costs real money per message. Rate-limit at the tool boundary, not in the prompt.

60. Google Calendar API — https://developers.google.com/calendar
Function: programmatic access to calendars, events, and free/busy information.
Agent use: checking availability and creating events as part of a scheduling task.
Constraint: recurring events and time zones are the two places calendar automation breaks. Handle both explicitly or the agent will produce confidently wrong times.

61. Cal.com — https://cal.com
Function: open-source scheduling infrastructure with an API and self-hosting option.
Agent use: booking against real availability rules without the agent needing direct calendar write access.
Constraint: the scheduling logic lives in booking rules you configure. Agents cannot reason their way past a misconfigured availability window.

62. Zoom — https://zoom.us
Function: video meetings with APIs for scheduling, recordings, and transcripts.
Agent use: creating meetings and retrieving recordings or transcripts for downstream summarisation.
Constraint: recording access is governed by account settings and consent requirements that vary by jurisdiction. Verify before an agent reads any recording.

63. Telegram Bot API — https://core.telegram.org/bots/api
Function: a bot platform with messaging, inline keyboards, and file transfer.
Agent use: a low-friction chat surface for personal and small-team agents with no app store review.
Constraint: bot tokens are bearer credentials with no scoping whatsoever. Possession of the token is total control of the bot.

---

Files and documents (63–72)

The recurring problem in this category is that agents receive files in formats designed for human eyes. Conversion fidelity is the whole game — a PDF table that flattens into a wall of unaligned numbers will produce a wrong answer with no error raised anywhere.

64. Google Drive API — https://developers.google.com/drive
Function: programmatic file storage, search, and permission management in Drive.
Agent use: locating documents by query and reading their content, including exporting native Google formats to text.
Constraint: permission changes made by an agent propagate immediately and are easy to make too broad. Never let an agent set link-sharing to anyone-with-the-link.

65. Dropbox API — https://www.dropbox.com/developers
Function: file storage with sync, versioning, and sharing APIs.
Agent use: reading from and writing to shared folders as part of document workflows.
Constraint: path-based addressing breaks when humans move files. Use file IDs where the API offers them.

66. Box — https://developer.box.com
Function: enterprise content management with governance, retention, and classification.
Agent use: document workflows in regulated environments where every access must be logged and retention enforced.
Constraint: classification and retention policies can block agent writes at runtime. Handle policy rejections as an expected outcome, not an exception.

67. Amazon S3 — https://aws.amazon.com/s3/
Function: durable object storage with fine-grained access policy.
Agent use: the standard place for agent-produced artifacts, intermediate files, and large tool outputs kept out of context.
Constraint: bucket policy misconfiguration is the classic cloud data exposure. Scope agent credentials to a prefix, block public access at the account level, and use presigned URLs with short expiry.

68. Notion API — https://developers.notion.com
Function: programmatic access to Notion pages, databases, and blocks.
Agent use: reading internal documentation and writing structured results back into a workspace humans already use.
Constraint: the block model is deeply nested, and rich page content requires recursive fetching. Rate limits make full-workspace traversal impractical — search first, then fetch.

69. Airtable — https://airtable.com
Function: a spreadsheet-database hybrid with a typed REST API.
Agent use: structured records with a human-editable interface, ideal for agent output that people need to review and correct.
Constraint: per-base record limits and API rate limits constrain both scale and write throughput. It is not a substitute for a database.

70. Confluence — https://www.atlassian.com/software/confluence
Function: enterprise wiki and documentation platform.
Agent use: retrieving internal knowledge and publishing generated documentation into the corporate knowledge base.
Constraint: content is stored in a specific storage format, not plain Markdown. Round-tripping through an agent without conversion damages formatting and macros.

71. Google Sheets API — https://developers.google.com/sheets
Function: read and write access to spreadsheet cells, ranges, and formatting.
Agent use: writing tabular results where non-technical users will filter, chart, and annotate them.
Constraint: cell values returned by the API may be formatted strings rather than raw numbers depending on the render option. Specify it explicitly or arithmetic silently fails.

72. Unstructured — https://unstructured.io
Function: document ingestion and partitioning across PDF, Office, HTML, and image formats.
Agent use: normalising a mixed pile of source documents into consistent, chunkable elements before retrieval.
Constraint: scanned documents depend on OCR quality, and OCR errors propagate silently into every downstream answer. Sample and inspect output for any new document class.

73. LlamaIndex / LlamaParse — https://www.llamaindex.ai
Function: document parsing and indexing tooling aimed at retrieval pipelines, including complex PDF layouts.
Agent use: extracting tables and structured content from documents where naive text extraction produces unusable output.
Constraint: high-fidelity parsing is a paid, latency-bearing operation. Parse once and cache the result rather than parsing per query.

---

Media (73–82)

Media tools are asynchronous by nature. A generation request that takes thirty seconds does not belong inside a synchronous tool call — submit, poll or receive a webhook, and let the agent do other work in between.

74. OpenAI Platform — https://openai.com/api/
Function: model APIs spanning text, image generation, audio, and embeddings.
Agent use: a single provider surface for generation, transcription, and embedding within one agent.
Constraint: consolidating on one provider makes model deprecations your migration problem on the vendor's schedule. Keep the model identifier in configuration.

75. Stability AI — https://stability.ai
Function: image and video generation models available via API and open weights.
Agent use: generating visual assets programmatically, including on self-hosted infrastructure.
Constraint: model licensing differs by model and by use case. Verify commercial terms per model rather than per vendor.

76. Black Forest Labs — https://blackforestlabs.ai
Function: the FLUX family of image generation and editing models.
Agent use: image generation and targeted image editing steps inside a content pipeline.
Constraint: editing quality is sensitive to prompt and mask construction. Agents need a verification step, since a plausible-looking wrong edit produces no error.

77. Replicate — https://replicate.com
Function: hosted inference for a large catalogue of open models behind one API.
Agent use: calling many specialised models without operating GPU infrastructure for any of them.
Constraint: cold starts on infrequently used models are slow and variable. Treat every call as asynchronous with a generous timeout.

78. fal — https://fal.ai
Function: an inference platform focused on low-latency generative media.
Agent use: interactive media generation where a user is waiting on the result.
Constraint: latency depends on the specific model endpoint. Benchmark the exact endpoint you will use rather than trusting a platform-level characterisation.

79. ElevenLabs — https://elevenlabs.io
Function: speech synthesis and voice tooling.
Agent use: generating spoken output for voice agents and narrated content.
Constraint: voice cloning carries consent and likeness obligations. This is a legal control, and it belongs at the tool boundary, not in a prompt instruction.

80. Deepgram — https://deepgram.com
Function: speech-to-text with streaming and batch modes.
Agent use: real-time transcription for voice agents that must respond while a person is still speaking.
Constraint: streaming transcripts are interim until finalised. Agents that act on interim text will act on words the speaker did not finish saying.

81. AssemblyAI — https://www.assemblyai.com
Function: speech recognition with speaker diarisation and audio intelligence features.
Agent use: turning multi-speaker recordings into attributed transcripts the agent can reason over.
Constraint: diarisation accuracy drops with overlapping speech and poor audio. Speaker labels are a hypothesis, not a fact.

82. FFmpeg — https://ffmpeg.org
Function: the standard command-line toolkit for audio and video processing.
Agent use: deterministic media operations — trimming, concatenating, transcoding, extracting frames — that need no model at all.
Constraint: it is invoked as a shell command, which is a command injection surface. Build arguments as an array, never by string interpolation of model output.

83. Cloudinary — https://cloudinary.com
Function: media storage with URL-driven transformation and delivery.
Agent use: producing derived assets by constructing a URL rather than running a processing job.
Constraint: transformation parameters live in publicly visible URLs. Anyone can modify them, so signed URLs are required where that matters.

---

Commerce and payments (83–88)

Payment tools are the category where a retry is not free. Every write operation an agent makes here must carry an idempotency key, because the difference between "the request failed" and "the response failed" is invisible to the caller and expensive to the customer.

84. Stripe — https://stripe.com
Function: payments, billing, subscriptions, and financial infrastructure with an extensively documented API.
Agent use: reading customer and subscription state, answering billing questions, and issuing refunds under policy.
Constraint: restricted API keys and idempotency keys are both mandatory for agent use. A retried charge without an idempotency key is a duplicate charge.

85. Shopify — https://www.shopify.com
Function: commerce platform with admin and storefront APIs for catalogue, orders, and fulfilment.
Agent use: order lookup, inventory checks, and customer service actions against live store data.
Constraint: the Admin API enforces cost-based rate limiting on GraphQL queries. Deeply nested agent-generated queries get throttled even at low request rates.

86. PayPal — https://developer.paypal.com
Function: payment processing and payouts.
Agent use: transaction status lookups and dispute-related workflows.
Constraint: sandbox and live environments behave differently in edge cases. Test dispute and refund paths in live conditions before trusting an agent with them.

87. Square — https://developer.squareup.com
Function: payments, point of sale, and business operations APIs.
Agent use: bridging in-person transaction data into agent workflows for reconciliation and support.
Constraint: OAuth permissions are per-merchant. Multi-location deployments need per-location scoping rather than one shared token.

88. Salesforce — https://www.salesforce.com
Function: CRM with a comprehensive API surface and a custom object model.
Agent use: reading account context and writing activity records so agent actions appear in the customer timeline.
Constraint: API call limits are governed per org per rolling window, and agents share that budget with every other integration. Cache aggressively.

89. HubSpot — https://www.hubspot.com
Function: CRM and marketing automation with REST APIs and webhooks.
Agent use: contact enrichment, deal updates, and reacting to lifecycle events.
Constraint: property definitions vary per portal, so no integration is portable across customers without a mapping layer.

---

Infrastructure and cloud (89–94)

Infrastructure tools give agents the ability to change what is running. The correct default is read-only. Promotion to write access should be per-action, time-bounded, and logged.

90. Amazon Web Services — https://aws.amazon.com
Function: the full cloud platform, addressable through a consistent API and SDK surface.
Agent use: inspecting resource state, reading logs and metrics, and executing narrowly scoped remediations.
Constraint: IAM is the entire security model and it is unforgiving. Scope agent roles by resource ARN and condition key, not by service.

91. Google Cloud — https://cloud.google.com
Function: cloud compute, data, and AI services with unified IAM and logging.
Agent use: querying operational telemetry and managing resources within a project boundary.
Constraint: predefined roles are broader than they read. Use custom roles for anything an agent holds.

92. Microsoft Azure — https://azure.microsoft.com
Function: cloud platform with resource management, identity, and monitoring APIs.
Agent use: infrastructure inspection and control in environments already standardised on Entra identity.
Constraint: role assignments inherit down the management-group, subscription, and resource-group hierarchy. Assign at the narrowest scope that works.

93. Cloudflare Workers — https://workers.cloudflare.com
Function: edge compute with attached storage, queues, and durable objects.
Agent use: hosting lightweight agent tools close to users, and running scheduled agent triggers.
Constraint: CPU time per request is capped and the runtime is not full Node.js. Long-running agent loops must be decomposed or moved.

94. Kubernetes — https://kubernetes.io
Function: container orchestration with a declarative API.
Agent use: reading pod status, events, and logs to diagnose why a workload is unhealthy.
Constraint: RBAC in a cluster is subtle, and a service account with broad read access can read every secret in its namespace. Restrict secret access explicitly.

95. Terraform — https://www.terraform.io
Function: declarative infrastructure as code with a plan-and-apply workflow.
Agent use: generating and explaining plans so a human can see exactly what would change before anything does.
Constraint: state files contain secrets in plaintext. An agent that can read state can read credentials — treat plan as safe and apply as human-gated.

---

Security, identity, and governance (95–100)

These are the tools that make the other ninety-four safe to give an agent. They are last on the list and first in the build order.

96. HashiCorp Vault — https://www.vaultproject.io
Function: secrets management with dynamic credentials, leasing, and revocation.
Agent use: issuing short-lived, task-scoped credentials so an agent never holds a long-lived secret.
Constraint: it introduces a hard dependency on the agent's critical path. Vault being unavailable means the agent cannot act at all — design that failure explicitly.

97. Auth0 — https://auth0.com
Function: identity and access management with token issuance and fine-grained authorisation.
Agent use: giving agents a verifiable identity and enforcing what that identity may do per resource.
Constraint: token lifetime is a direct trade-off between security and long-running task viability. Long agent runs need refresh handling, not longer tokens.

98. 1Password — https://1password.com
Function: credential management with service accounts and programmatic secret retrieval.
Agent use: fetching credentials at call time instead of baking them into environment variables or configuration files.
Constraint: a service account token is itself a high-value secret. Scope it to specific vaults and rotate on a schedule you actually enforce.

99. Semgrep — https://semgrep.dev
Function: static analysis with customisable pattern-based rules.
Agent use: automatically scanning agent-generated code before it reaches a pull request.
Constraint: static analysis produces false positives, and an agent that treats every finding as blocking will loop. Classify rules by severity and act only on the blocking set.

100. Snyk — https://snyk.io
Function: dependency, container, and infrastructure-as-code vulnerability scanning.
Agent use: checking whether a dependency an agent proposes adding introduces a known vulnerability.
Constraint: advisory data lags disclosure. A clean scan means no known issue, which is not the same as no issue.

---

Selection matrix

Most tool decisions are made on features and regretted on operations. These are the dimensions that actually determine whether a tool survives inside an autonomous loop, with the question to ask and the answer that should end the evaluation.

Dimension	Question to ask	Disqualifying answer
Output shape	Does it return structured data with a stable schema?	Free-form prose that must be re-parsed by the model on every call
Idempotency	Can the same call be retried safely?	Writes with no idempotency key and no dedupe on the server side
Auth granularity	Can I issue a credential scoped to one resource and one action?	Only account-wide keys with full read and write
Failure semantics	Does it distinguish "not found" from "not permitted" from "temporarily unavailable"?	A single generic error for every condition
Latency profile	Is p99 latency compatible with a synchronous tool call?	Multi-second p99 with no async submit-and-poll option
Rate limits	Are limits documented, and does the response say when to retry?	Undocumented limits, or throttling with no Retry-After
Blast radius	What is the worst thing one wrong call can do?	Irreversible external effect with no dry-run or preview mode
Cost per call	Can a runaway loop generate unbounded spend?	Usage-billed with no hard cap available
Observability	Can I trace a specific agent call in the vendor's own logs?	No request ID returned to the caller
Determinism	Do identical inputs produce identical outputs?	Non-deterministic results with no way to pin a version

Two rules that fall out of this matrix and are worth stating on their own.

Prefer narrow tools over general ones. A refund_order(order_id, amount, reason) tool is safer, more reliable, and easier to evaluate than a call_payments_api(method, path, body) tool, even though the second is more capable. Capability you expose is capability you must defend.

Prefer tools with preview modes. Anything that supports a dry run — terraform plan, an email draft, a database transaction the agent can inspect before commit — converts an irreversible action into a reviewable one. That single property is worth more than most feature comparisons.

---

Secure tool-use checklist

Work through this before an agent touches production. Each item exists because skipping it produces a specific, recurring failure.

Credentials

• Every tool gets its own credential. Shared keys make attribution impossible after an incident.
• Credentials are scoped to the narrowest resource and action set the tool needs.
• Secrets are fetched at call time from a secret manager, never read from a prompt, a config file in the repo, or a model-visible variable.
• Rotation is scheduled and tested. An untested rotation procedure is a future outage.
• No credential appears in tool arguments, tool results, traces, or logs. Verify this by grepping your own telemetry.

Permissions

• Read and write are separate tools with separate credentials, not one tool with a mode flag.
• Destructive operations require an explicit human approval step that names the specific resource affected.
• The agent operates under a delegated identity where the platform supports it, so it cannot exceed the permissions of the person who asked.
• Multi-tenant systems enforce tenant isolation server-side. Filtering by tenant in the prompt is not isolation.

Input and output handling

• Every tool argument is validated against a schema before execution, not after.
• Command construction uses argument arrays. No shell string interpolation of model output, ever.
• SQL is parameterised or generated through a query builder with an allowlist of tables and columns.
• Tool output is treated as untrusted input. Content fetched from the web can contain prompt injection, and it must not be able to reach a privileged tool without passing a filter.
• Large outputs are truncated or summarised at the tool boundary so a single call cannot exhaust the context window.

Execution safety

• Untrusted code runs in an isolated sandbox with no network access by default and no host mounts.
• Every tool call has a timeout. Every agent run has a wall-clock budget and a maximum step count.
• Retries use exponential backoff with jitter and a hard attempt cap.
• Write operations carry idempotency keys derived from the task, not generated fresh per attempt.
• Spend limits are enforced by the runtime, not requested in the system prompt.

Observability and recovery

• Every tool call emits a span with the tool name, redacted arguments, latency, outcome, and the vendor's request ID.
• Failures are logged with enough context to reproduce the call by hand.
• Every write action has a documented reversal procedure, and someone has run it.
• There is a kill switch that stops all agent tool execution without a deployment.
• Tool usage is reviewed periodically for scope creep. Permissions granted for one feature outlive that feature.

---

Frequently asked questions

How many tools should one agent have?
Fewer than you think. Selection accuracy degrades as the tool list grows, and the failure mode is subtle: the model picks a plausible neighbouring tool rather than the right one. If an agent needs a large capability surface, split it into specialised sub-agents with small toolsets and route between them, or load tool groups dynamically based on the task.

Should tools be exposed through MCP or as native function definitions?
MCP when the tool is shared across multiple agents, clients, or teams, because you get one implementation and one place to update it. Native definitions when the tool is specific to one agent and benefits from tight coupling to that agent's state. Most production systems end up with both. The catalogue of ready-made servers is in the 100 best MCP servers.

What is the difference between this list and the skills list?
This list is capabilities an agent can invoke. The skills list is procedures that tell an agent when and how to invoke them. A tool without a skill is a capability nobody uses correctly. A skill without tools is advice.

Do I need a framework to use these tools?
No. Any language with an HTTP client and a model API can call tools directly, and for a single-purpose agent that is often the right choice. Frameworks earn their weight when you need persistent state, multi-step planning, parallel execution, retries, and tracing as first-class concerns. That trade-off is covered in best AI agent frameworks.

How do I stop an agent calling the wrong tool?
Three things, in order of effectiveness. Write tool descriptions that state when not to use the tool, not only when to use it. Make tool names and argument names unambiguous, since the model reasons over those strings. Reduce the number of tools available for a given decision. Prompt instructions to "be careful" do not change selection behaviour.

Should agents be allowed to write to production databases?
Only through narrow, purpose-built tools that encode the allowed operation, never through a general SQL execution tool. Give the agent update_order_status(order_id, status) rather than execute_sql(query). The general tool is easier to build and impossible to reason about.

What about tool call cost?
Cost has two components: the model tokens spent on the tool schema and the result, and the vendor charge for the call itself. Large tool schemas are paid on every single model invocation, so verbose descriptions across many tools are a persistent tax. Trim schemas, truncate results at the boundary, and cache anything that does not change within a run.

How do I handle tools that take minutes to complete?
Do not block the loop. Split into a submit tool that returns a job identifier and a status tool the agent polls, or use webhooks to resume the run when the job finishes. Agents blocked on long synchronous calls hit timeouts and retry, which duplicates the work you were waiting for.

How should I evaluate a tool before adopting it?
Run it against the ten dimensions in the selection matrix, then write a small evaluation set of real tasks and measure how often the agent calls it correctly and how often the result is usable. Feature comparisons predict very little about behaviour inside an autonomous loop.

Where do I start if I want these connected without writing integration code?
See /integrations/ for the connectors already wired into AGNT, including auth handling and scoped credentials, so the first thing you build is the agent rather than the plumbing.

Run these tools through AGNT

AGNT gives these APIs and utilities somewhere durable to run: inside an agent, a visual workflow, a long-running goal, a plugin, or an MCP connection, with local traces and approval gates around consequential actions. Download AGNT and connect the tools you already use.

---

What to do with this list

Do not adopt breadth. Pick the two or three tools that unblock the specific task your agent exists to perform, wire them with scoped credentials and the checklist above, and measure whether the agent calls them correctly. Then add the fourth.

The teams that struggle with agents in production almost never lack capability. They gave the agent forty tools, no observability, and one shared API key, and now they cannot tell which of the forty produced the wrong answer.

Start narrow. Instrument first. Expand on evidence.