Fillo

Show this connection's workspace, project, and capabilities

fillo_whoami

Read-onlyIdempotent

Report which Fillo workspace and project this connection is bound to, the capabilities the user granted on the consent screen, and the publish approval policy. Use it to orient before reading or writing anything. Never returns token material.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`client`	Yes	The connected OAuth client's display name.
`scopes`	Yes	Scopes this connection's key holds.
`project`	Yes	The bound project (id always present; name/slug when resolvable).
`workspace`	Yes	The bound workspace (id always present; name/slug when resolvable).
`capabilities`	Yes	Human-readable capability labels resolved from the granted scopes.
`publishPolicy`	Yes	Legacy name for approvalPolicy — same value, kept for existing clients.
`approvalPolicy`	Yes	The grant's approval policy for outward actions (publish, unpublish, release, re-send, enable integrations, invites, role changes, code-sync policy, origins, identity): ask = a human approves each via a single-use link; auto = runs directly when the scope is granted. Destructive actions (deletes, removals, revocations) always need the link.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 24, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: what fields are surfaced (capabilities, publish approval policy) and the security-relevant guarantee 'Never returns token material.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place, with the returned resources front-loaded and the usage hint and safety note following. No padding or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not required. For a no-arg orientation tool with full annotation coverage, nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is empty, so the baseline of 4 applies. There are no parameter semantics for the description to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Report) and enumerates exactly what is returned: bound workspace, project, consent-screen capabilities, and publish approval policy. This clearly separates it from the many list_/get_ siblings as a connection-orientation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use it to orient before reading or writing anything" gives a clear condition for invocation. It lacks an explicit when-not or an alternative tool, but as a bootstrap tool that routing is largely unnecessary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Fillo tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.