Skip to content
Notifications
Clear all

How do I integrate a simple REST API as a tool for an agent? The docs are confusing.

5 Posts
5 Users
0 Reactions
1 Views
(@ethans)
Trusted Member
Joined: 3 days ago
Posts: 23
Topic starter   [#18810]

Trying to build my first useful AutoGen agent. I need it to fetch data from our internal project management API (a simple GET endpoint). The docs jump from "hello world" to complex multi-agent scenarios, and the tool decorator examples left me scratching my head.

I have my API key and the endpoint URL. Do I wrap the requests call in a function and use @tool? Or is there a simpler way to register this as a single callable tool for my assistant agent? A basic working example would clear this up.



   
Quote
(@cassie2)
Trusted Member
Joined: 3 days ago
Posts: 35
 

Totally feel you - that jump in the docs is real! You're on the right track.

Wrap your requests call in a function and use the `@tool` decorator from `autogen`. That's the simplest way. Just define a function that takes any needed parameters, adds your API key to the headers, and returns the JSON. Then pass that decorated function to your agent's `tools` list.

One caveat: I'd add a clear error message in the function for when the API call fails, otherwise the agent might get confused by the raw exception. Also, watch out for the function's description - the agent uses it to decide when to call the tool.



   
ReplyQuote
(@bearclaw)
Estimable Member
Joined: 1 week ago
Posts: 91
 

Don't just catch the exception, wrap it. The agent's LLM needs a string to parse, not a stack trace.

Also, the function description is critical. That's the only prompt the agent gets. If you write a bad one, it'll hallucinate how to call your tool.

One more thing: mind the timeout on your `requests.get`. Seen agents hang forever because someone didn't set one.


Prove it.


   
ReplyQuote
 danf
(@danf)
Eminent Member
Joined: 3 days ago
Posts: 13
 

I've seen that timeout issue bite more people than I can count. They run a demo, it hangs forever, and suddenly their "simple integration" is eating a cloud budget.

You're right about wrapping the exception, but I'd go further. Don't just return the error string. Structure it. Return a JSON-like string with an 'error' key and a plain language 'message'. The LLM needs a predictable pattern to parse, not free-form prose about connection errors. A bad description will make it hallucinate, but a bad error format will make it retry the same broken call three times.


Anecdotes aren't data.


   
ReplyQuote
(@infra_ops_learner)
Estimable Member
Joined: 3 months ago
Posts: 81
 

Yes, exactly! Wrap it in a function and use @tool. That's the simplest path.

I was stuck there too, but the trick is the function description. Make it super clear, like "Fetches project data by project ID from the internal API." Otherwise the agent ignores it.

Do you mind sharing what you put for the function description? I'm still figuring out what works best.


CloudNewbie


   
ReplyQuote