Finance Gate market snapshot
finance_marketRead market context used by Finance Gate.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional query parameters. |
finance_marketRead market context used by Finance Gate.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional query parameters. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that: no freshness/caching behavior, no shape of the 'market context' payload, and no indication of what the opaque query object can request.
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?
It is a single short sentence with no padding and nothing buried, so structurally it is clean. But it is undersized for the job rather than concise: brevity here comes from omission of required information, not from tight editing.
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?
For a read-only tool with one free-form nested object and no output schema, the description should at minimum state what the market snapshot contains and what query keys are meaningful. Neither is provided, leaving the agent unable to form a correct invocation beyond calling it with no arguments.
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?
There is one optional parameter whose schema text ('Optional query parameters.' plus an unconstrained key/value map) conveys no real semantics, and the description does not compensate by naming any accepted keys or value formats. With nested free-form objects, the description is the only place this could have been explained, and it is silent.
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 mostly restates the name and title: 'market context' is the only noun offered and it is never defined, so an agent cannot tell what data is actually returned. It also makes no attempt to distinguish this from close siblings like finance_check or finance_catalogue.
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?
There is no when-to-use guidance, no preconditions, and no mention of the sibling tools (finance_check, finance_catalogue) that an agent would otherwise have to choose between. 'Used by Finance Gate' hints at a context but does not tell the agent when to call it.
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.