Returns Fodda's main capabilities / features / offerings / products / services / tools and how to use them. Call this for any question about what Fodda can do or what's available.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | No | Optional user identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the output includes main offerings and usage instructions, which is genuinely behavioral information beyond the read-only/idempotent annotations. It doesn't explain response structure or whether the optional userId affects output, but the annotation already covers safety and the description conveys what the tool tells the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and front-loaded: the first sentence states what it returns, the second gives the usage rule. The string of synonyms is mildly redundant, but not a meaningful waste of tokens and still succeeds in covering the concept of capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero required parameters, a single optional userId, no output schema, and a short capability/help role, the description fully covers what the agent needs to call it correctly. It explains the returned content, usage intent, and relationship to 'what's available. Nothing important is left unsaid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single optional 'userId' parameter with a clear description, and schema coverage is 100%. The tool description adds no extra meaning about how userId influences the returned capabilities, so parameter-semantics sits at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb ('Returns') and a clear resource ('Fodda's main capabilities... and how to use them'). The phrase 'Call this for any question about what Fodda can do or what's available' sharpens the purpose and makes it easy to distinguish from data-access siblings like search_graph or get_evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call the tool ('for any question about what Fodda can do or what's available'), giving a clear trigger condition. It does not name sibling alternatives or describe when not to use it, but the context is strong enough for a help-like capabilities tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The tools are mostly distinct: search_graph, get_node, get_neighbors, get_evidence, and get_label_values all relate to graph exploration, but each has a clear role (search vs. profile vs. relationships vs. evidence vs. label enumeration). consult_analyst and consult_human_agent are similar in purpose and wording, but the 'Synthetic' vs. 'Human Agent' distinction in names and descriptions is sufficient to keep them separated.
All tools follow a consistent snake_case verb_noun pattern, with sensible verbs like get_, list_, search_, request_, check_, consult_, and generate_. The paired request_deliverable / check_deliverable_status and list_analysts / consult_* relationships are clear and predictable.
14 tools is well within the ideal 3–15 range and each tool appears justified: graph discovery, trend exploration, evidence retrieval, expert consultation, deliverable commissioning, visual generation, account/capability introspection, and analyst listing. No redundant extras or obvious bloat.
The tool set covers the full workflow promised by the server: discovering graphs and analysts, searching and drilling into trends, retrieving evidence, consulting experts, commissioning and polling deliverables, generating visuals, and checking account status. There are no significant dead ends or clearly missing operations for the stated expert-consultation purpose.