hf_whoamiInspect the current Hugging Face authentication context, including the account, visible organization memberships, and credential access details. Read-only and never returns credential values.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by explicitly stating it is read-only and 'never returns credential values', providing a strong security guarantee. This goes beyond the annotations, though it partly repeats the read-only hint.
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?
The description is concise and front-loaded, using two sentences to convey purpose, scope, and a key security property. Every word earns its place without waste.
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?
Given the tool's simplicity (no parameters), the presence of an output schema, and clear annotations, the description adequately covers the essential contextual information. It explains what the tool does, its read-only nature, and credential safety, making it complete for an agent to select and invoke correctly.
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 tool has zero parameters, so the baseline is 4. The schema coverage is vacuously 100%, and the description correctly avoids inventing parameter details. No additional parameter explanation is needed.
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 clearly specifies the tool's function with a specific verb ('inspect') and resource ('Hugging Face authentication context'), listing the exact data covered (account, org memberships, credential access details). It distinguishes itself from sibling tools focused on file systems or repo operations.
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?
The description clearly implies its purpose, but it does not explicitly state when to use this tool versus alternatives like hf_fs or hub_repo_details. No when-not-to-use guidance is provided, so usage context is implied rather than explicit.
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.
hf_fs is a multi-purpose tool with search, ls, stat, and cat subcommands that overlap significantly with hub_repo_search and hub_repo_details. An agent could easily select the wrong tool for searching repos or retrieving details, as both hf_fs and hub_repo_search expose search capabilities and both hf_fs's stat and hub_repo_details provide metadata.
The tool names use inconsistent prefixes: 'hf_fs' and 'hf_whoami' versus 'hub_repo_details' and 'hub_repo_search'. This creates two naming conventions (hf_ vs hub_repo_), and hf_fs does not follow the descriptive pattern of the other tools.
With only 4 tools, the count is not excessive, but hf_fs is overloaded with many subcommands while the other tools are narrowly scoped. This makes the tool distribution uneven, though the total number is within a reasonable range.
The set covers read-only operations well: searching, listing, reading files, retrieving repo details, and checking auth. However, there are no write operations (create, update, delete) for repositories or files, and dataset preview is only available through hub_repo_details, which might be a gap for dataset-focused workflows.