agent_access_statusWhere this caller stands: whether the bearer token verified, the entitlement tier behind it (checked fresh, never trusted from the token), today's tool-call meter, and how to get full access. Call this first when a subscriber tool is missing from tools/list or a call is refused.
| 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 idempotentHint=true, reducing the need for behavioral disclosure. The description adds valuable context (e.g., checking fresh entitlement, not trusting token) but does not elaborate on potential side effects or error conditions, which is acceptable given the annotations.
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 succinct sentences front-load the key purpose and usage. Every sentence adds value without redundancy, making it highly efficient for an agent to parse.
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, no output schema, but with annotations), the description covers purpose, usage, and behavioral details comprehensively. An agent can correctly understand when and how to invoke this tool.
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?
With zero parameters and 100% schema coverage, the description adds no parameter-specific information, which is appropriate. The baseline score of 4 applies as the description compensates by clarifying the tool's overall function.
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 states what the tool does: provides caller's access status, bearer token verification, entitlement tier, tool-call meter, and instructions for full access. It distinctly serves as an access and meter check, differentiating it from sibling tools like depth_episodes or sealed_record.
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?
Explicitly states when to call: 'Call this first when a subscriber tool is missing from tools/list or a call is refused.' This provides clear, actionable guidance, leaving no ambiguity about its primary use case.
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.
Each tool targets a distinct aspect of market liquidity: access status, historical depth episodes, current exit costs, liquidity overview, trust record, fund unwind, venue concentration, and price reconciliation. No two tools overlap in purpose.
All tool names use a consistent lowercase_snake_case noun phrase pattern (e.g., depth_episodes, exit_cost, venue_concentration). This is predictable and coherent, even though the convention is not verb_noun.
Eight tools is well within the ideal 3-15 range for a specialized analytics server. Each tool provides a unique function without redundancy or bloat.
The tool set covers the domain thoroughly: current liquidity state (exit_cost, venue_concentration, venue_price_reconciliation, liquidity_tiers), historical events (depth_episodes), risk assessment (unwind_watch), and platform meta (agent_access_status, sealed_record). No obvious gaps for the described purpose.