fusion-query-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have crisp distinct purposes, and the domain prefixes (docs_, api_, soap_) in names do real disambiguation work. However, there are several deliberate parallel pairs — live vs docs-snapshot describe/search, run_query vs adhoc_query vs run_report, validate_report vs validate_query — whose boundaries are only clear after reading the lengthy descriptions, so a skimming agent could easily pick the wrong query or validation path.
Naming Consistency4/5
The set overwhelmingly follows fusion_<verb>_<noun> (or fusion_<module>_<verb>_<noun> for docs_/api_/soap_), which is a strong, predictable convention across 40 tools. A few outliers break the verb-first shape — fusion_health_check, fusion_adhoc_query, fusion_bootstrap — but they remain readable and do not undermine the overall pattern.
Tool Count3/5
40 tools is heavy and exceeds the comfortable band, though the count reflects a genuinely broad scope: SQL, BI reports, REST, SOAP, ESS/FBDI, approvals, pods, and docs each form their own cluster. The live-vs-docs-snapshot duplications and the three overlapping query execution paths inflate the number without adding new capability, making the surface larger than it needs to be.
Completeness4/5
The surface covers the full lifecycle across channels: schema exploration, query execution (report, ad-hoc, free-SQL), validation with fixtures, guarded write actions (REST, SOAP, ESS, FBDI), monitoring (job status/log, health check), and repair (bootstrap, interface-data correction). Minor gaps exist — no fixture deletion, no report deletion, no direct REST record GET by ID, no job cancellation — but all are workable around or explained as inherent constraints.
Average 4.7/5 across 40 of 40 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful context beyond that: the snapshotted nature of the service and the warning that parameter order matters and can cause silent, incorrect calls. This is valuable behavioral disclosure.
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?
The description is compact, front-loaded with the core purpose, and uses a clean Args section. The positional-order warning is not padding; it is high-value guidance directly relevant to calling Fusion operations safely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description does not need to explain return values or side effects. Both input parameters are documented and the crucial positional-order caveat is included. The only real gap is explicit routing guidance relative to sibling tools.
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?
Schema description coverage is 0%, so the description must carry parameter meaning. It documents both parameters: service with a concrete path example and operation as optional. This adds real value beyond the schema, though it could be slightly richer about operation name format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as one that returns operations of a snapshotted SOAP service, optionally detailing a single operation. This makes the resource and action clear, and distinguishes it from call/list tools in the sibling set. It stops short of explicitly naming a sibling it is not, so it does not fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied through the positional-parameter warning: an agent should inspect operation parameter order before making calls. However, the description never explicitly says when to use this tool versus fusion_soap_call or fusion_soap_list_services, and it offers no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the safety profile is fully covered. The description adds useful domain context about silent row multiplication and the SQL scope, but it does not disclose operational details such as return format, errors, or response size. The output schema appears to cover return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-line purpose and then provides a brief, relevant example of the silent-corruption trap. The args section is compact and complete. The middle paragraph is slightly verbose but every sentence contributes meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter, read-only knowledge tool with an output schema, the description is nearly complete: it covers purpose, usage timing, parameter values, and omission behavior. It does not name sibling alternatives or exclusions, but those are not essential for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a nullable string `topic` with no enum or description, so 0% schema coverage means the description must compensate. It does so excelently by listing all accepted topic values and explicitly stating that omitting the argument returns the whole base. This fully resolves parameter ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies this as a knowledge-retrieval tool for curated Oracle Fusion schema traps, specifically the silent data-corruption risks in joined results. It is clearly distinct from the sibling query, validation, and report tools, but it lacks an explicit verb like 'retrieve' and does not directly contrast itself with a sibling.
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?
The description gives a concrete use condition: 'Read the relevant topic before trusting a joined result.' It also explains the failure mode that motivates the tool—missing `_TL` or `_F` predicates multiply rows silently. However, it does not explicitly state when not to use the tool or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations: it explains why destructiveHint is true (queued process cannot be recalled, not business-data mutation), discloses the comma-joining rule, the refusal of comma-containing parameters, and the explicit user confirmation requirement. This is exactly the context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into a purpose statement, a behavioral note, and an Args block, and every section has a purpose. It loses a point because it contains the inaccurate schema-reference sentence, which adds confusion rather than value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers purpose, destructive nuance, confirmation, and parameter semantics (albeit with one error), and an output schema exists so return values needn't be detailed. It is incomplete in that the parameter-format contradiction undermines the agent's ability to invoke the tool confidently; it also does not point to the job-status sibling for tracking after the async queue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful detail for job_name, notification_code, and confirmed, but its parameter guidance conflicts with the input schema. It claims the schema declares 'parameterList' as a single string and instructs that parameters are 'joined with commas,' while the actual schema declares parameters as an array of strings. This is misleading for invocation.
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?
The description opens with a specific verb and resource: 'Run an extract job and leave its output in UCM.' It returns a request id, and states it is the mirror of fusion_import_bulk_data, which clearly differentiates it from the import sibling and the generic fusion_submit_job.
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?
It names the sibling mirror and explicitly contrasts the parameter format with fusion_submit_job, giving clear context for selection. It does not, however, spell out explicit 'use when/when-not' criteria, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which strongly cover the safety profile. The description adds minimal behavioral context beyond saying the fixtures are saved and are for validation, but it does not contradict the annotations or present any surprise behavior.
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?
A single sentence delivers the action, resource, and purpose without wasted words. The core function is front-loaded and easy to scan.
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?
For a zero-parameter read-only listing tool with strong annotations and an output schema, the description is complete. It tells the agent what will be listed and why, while the structured metadata covers safety and return shape.
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 has zero parameters and the input schema is fully described by having an empty properties object. There is no parameter documentation burden for the description, so the baseline of 4 applies.
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?
The description uses the specific verb 'List' with an explicit resource ('saved ground-truth fixtures') and states the purpose ('available for validation'). This clearly distinguishes it from sibling tools like fusion_save_fixture and fusion_get_fixture, which imply writing and retrieving individual fixtures rather than enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. However, the phrase 'available for validation' implies the tool is for enumerating saved fixtures before selecting one, so some usage context is present but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable context by clarifying that the service list is a snapshot, that operation counts are included, and that the SOAP surface extends beyond REST resources. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the essential definition in the first sentence, then adds useful context about why SOAP services matter and how snapshots are produced. The third sentence references an external CLI command, which is slightly tangential but still helps explain the snapshot origin without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema and strong annotations, the description is largely complete. It explains what is returned (services with operation counts), the pod scope, and why this tool is useful. It could be slightly stronger by explicitly routing to fusion_soap_describe for detailed service inspection, but that gap is minor given the available structured metadata.
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 has zero parameters and the input schema is empty, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because there is no parameter information missing that the description would need 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?
The description states a specific verb ('list') and resource ('SOAP services snapshotted for this pod'), and adds that operation counts are included. It clearly distinguishes itself from the sibling tools fusion_soap_describe and fusion_soap_call by focusing on the inventory of services rather than inspecting or invoking a single service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool to discover available SOAP services that are not exposed through REST, especially when exploring functionality like purchase order change orders or BI Publisher catalog administration. However, it does not explicitly say when to choose this tool instead of fusion_soap_describe or fusion_soap_call, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnlyHint/openWorldHint/idempotentHint/destructiveHint) by explaining how `outcomes` is derived from the task's `actionList` with System entries filtered out, and by explicitly warning that an EMPTY outcomes list is a real common state, not an error, with a concrete observed pod example. This is exactly the interpretive context that structured annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose in the first line and each paragraph earns its place: operational guidance, edge-case semantics, and argument sourcing. The observed-pod anecdote is slightly longer than strictly necessary, but it reinforces a non-obvious behavior, so the length is justified.
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?
With an output schema present and annotations covering the read-only/idempotent safety profile, the description fully covers everything else an agent needs: what the tool returns, the non-obvious meaning of empty outcomes, why it can be empty (assigned group not acquired), and where to obtain the single argument. No critical gap remains for a single-parameter read tool.
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?
Schema description coverage is 0% — the schema only names the parameter "Number" with type string — so the description carries the full burden. It compensates by specifying the provenance: "The task number from `fusion_list_tasks`," which is the key semantic an agent needs to populate the argument correctly. It stops short of 5 because it doesn't hint at string format or any transformation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
"One task in full, including the outcomes this user may actually submit" clearly identifies the resource (a single task) and the distinctive content (actionable outcomes), which separates it from fusion_list_tasks (list view) and fusion_act_on_task (taking action). However, no explicit verb like "read" or "get" is present — the intent is stated as a noun phrase, so it stops just short of a 5.
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?
The description gives clear operational context: read `outcomes` before offering the user a choice, and the `number` argument comes from `fusion_list_tasks`. It implicitly establishes when to call this tool (when full task detail and the user's actual decision options are needed), but it does not explicitly name exclusions or alternative siblings to consider instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, so the bar is lower. The description adds useful behavioral context beyond annotations: it is the 'cheapest way' to perform this verification and it scopes results to a UCM account. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is front-loaded with the core action, followed by a practical use-case sentence and a clean Args section. The failure-mode explanation earns its place because it clarifies why this tool matters. Minor redundancy exists with 'Read-only' duplicating the readOnlyHint annotation.
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?
For a simple two-parameter read-only search tool, the description covers purpose, parameter semantics, and the key usage scenario. The output schema exists to document return values, and annotations cover safety and idempotency, so nothing critical is missing for an agent to select and invoke it correctly.
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?
Schema description coverage is 0%, so the description must compensate. It does: both parameters are explained with plain semantics, and 'account' includes a concrete format example, `fin$/payables$/import$`. It could add details like case-sensitivity or wildcard behavior, but it is sufficient for correct invocation.
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?
The description opens with a specific verb and resource: 'List UCM document ids matching a file prefix in an account.' It clearly distinguishes the tool from job-status and import tools by framing it as the way to check whether an upload actually landed in the right place.
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?
The description gives a concrete when-to-use scenario: verifying that a bulk upload landed in the correct account, including the characteristic failure mode of files sitting in accounts no import job looks at. It does not explicitly name alternative sibling tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the return content ('expectations and stored SQL') but does not disclose failure behavior, errors, or other behavioral details. This is adequate but minimal beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and one argument note, with the core behavior front-loaded and no wasted words. Every sentence earns its place.
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?
For a single-parameter read-only tool with rich annotations and an output schema present, the description is complete: it states what the tool reads, what the result includes, and where to obtain the required parameter. Nothing essential is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the semantic weight for the only parameter. 'The fixture name as reported by fusion_list_fixtures' fully defines what 'name' means and gives the agent an exact source for the value, which is significantly more meaningful than the schema's bare string type.
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?
The description clearly states a specific action ('Read') and a specific resource ('one saved fixture'), and further details what is included ('expectations and stored SQL'). It also distinguishes itself from sibling fusion_list_fixtures by focusing on a single fixture, so an agent can tell the tools apart.
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?
The description gives clear context by saying the name must come from 'fusion_list_fixtures', which is a practical instruction for invoking this tool correctly. It does not explicitly state when not to use it or name alternatives, but the source-of-name guidance is sufficient for this simple case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond annotations: redacted-column values are masked before writing, and sql is stored alongside for reference. Annotations already indicate the operation is not read-only and not destructive; no contradiction is present.
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?
The description is front-loaded with the core purpose, gives a short rationale, and then uses a compact, labeled Args section. Every sentence contributes either to selection, usage timing, or parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter write operation with an output schema, the description is nearly complete: it covers all params, the masking behavior, and the persistence intent. It does not spell out what happens when overwrite is false and a fixture already exists, so there is a small but non-fatal gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args block fully compensates by explaining all six parameters, including the name character restriction, the purpose of expectations, and the overwrite replacement behavior. This is exactly what an agent needs to fill the arguments correctly.
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?
The description opens with a specific verb and resource: 'Persist a validated set of expectations as a reusable regression test.' This clearly distinguishes fusion_save_fixture from retrieval siblings like fusion_get_fixture or fusion_list_fixtures.
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?
It gives an explicit trigger ('Worth doing every time a validation passes') and explains why with the quarterly patch example. It does not name a specific alternative or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description adds substantial behavioral context: it runs a registered report with specific bind values, orders results by table row-count statistics, applies no row cap internally so limit is enforced here, and reports 'truncated' honestly. It also explains that datasource is ignored on the report path, which is valuable non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a crisp one-line purpose and then progresses through report behavior, ordering, limit handling, and per-argument details. It is somewhat verbose in the ordering explanation with examples like 'interface, history and staging namesakes', but that detail is informative rather than filler. Overall it earns its length.
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?
Given the tool's complexity, the presence of an output schema, and rich annotations, the description is complete for invocation. It explains every parameter, the report execution path, the ordering heuristic, and the limit/truncation semantics. No critical operational detail needed to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It does this thoroughly: pattern is defined as a SQL LIKE pattern with an example, owner is explained as optional with a report default, table_pattern is described as an optional LIKE restriction, limit is defined as the maximum rows returned, and datasource is disclosed as a legacy fallback that is ignored on the report path. This goes well beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific purpose: 'Find which tables carry a column' and positions it as 'the fastest answer to where does X live?'. This is a concrete verb+resource statement. However, it does not explicitly distinguish itself from the similar sibling fusion_docs_search_columns, so it stops short of full sibling differentiation.
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?
The description clearly establishes when to use the tool: when you need to locate which tables contain a column, framed as the fastest answer. It also gives practical usage context such as LIKE patterns and the limit behavior. It does not explicitly state when not to use it or name alternatives, but the primary use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful traits beyond that: it is instant, local, and requires no pod round trip. It also clarifies that limit applies per kind rather than globally, which is valuable behavioral detail not present in the schema.
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?
The description is compact and purpose-led. The first sentence states what it does, the second gives the primary usage scenario with a realistic example, and the Args section cleanly documents parameters. No redundant phrasing or unnecessary details.
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?
For a simple two-parameter search tool, the description covers purpose, invocation semantics, parameter behavior, and a realistic workflow example. The presence of an output schema means return-value documentation is not required, and annotations cover the safety profile. The tool is fully scoped against its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains term as a substring match across resource names, field names, and business descriptions, and explains limit as maximum matches per kind. This is significantly richer than the bare schema properties and leaves no ambiguity about either parameter.
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?
Description opens with a specific verb and resource: 'Find REST resources and fields by name or business meaning.' It also includes a concrete example mapping a user phrase to an API field name, which clearly differentiates this search tool from siblings like fusion_describe_table or fusion_search_columns.
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?
The description gives a clear use case: when the user mentions a business concept, use this tool to translate it into the expected field name before asking clarifying questions. It also notes the local, no-pod-round-trip behavior. However, it does not explicitly mention alternatives or when not to use this tool versus nearby siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive behavior. The description adds substantial behavioral detail beyond annotations: the case-sensitive dual-object rule, chosen_by tie-breaking logic, ambiguous flag, alternates list, no-silent-resolution guarantee, and the datasource fallback behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is front-loaded with the core purpose and uses clear headers for complex rules. The dual-object rule justifies much of the length, though some narrative explanation could be trimmed without losing essential guidance.
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?
With an output schema present, return values need not be re-explained. The description covers invocation timing, parameter semantics, ambiguity behavior, and re-call guidance, making it functionally complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully carries parameter meaning. It explains table as 'OWNER.OBJECT' with case preservation, owner as the fallback schema when table is unqualified, and datasource as a legacy ignored path. This goes well beyond the bare schema properties.
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?
The description opens with a specific verb and resource: 'Describe ONE Fusion object: ordered columns, data types, comments.' It clearly distinguishes this from list/search/sibling documentation tools by emphasizing 'ONE' object and precisely naming the output elements.
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?
It gives explicit usage guidance: 'Call this before writing any query that names a column' and explains the concrete cost of guessing wrong. However, it does not explicitly say when to prefer alternative tools like fusion_docs_describe_table or fusion_search_columns, so it stops short of full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining the security boundary, why arbitrary SQL cannot work, how reports are registered, and what each result contains: parameters and defaults. It also discloses that unknown bind parameters are rejected before a round trip. This aligns with the readOnly and idempotent hints and adds meaningful behavioral context.
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?
The description is longer than average but every sentence earns its place: it front-loads the purpose and 'Call this FIRST', then explains why reports are the only path, what the listing contains, and how to handle missing reports. There is no repetition or filler.
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?
For a zero-parameter, output-schema-backed listing tool, the description is fully complete. It covers invocation order, the meaning of results, the security model, and the fallback behavior when no report fits. The presence of an output schema means return-value details do not need to be repeated.
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 has zero parameters and the input schema fully covers this with 100% coverage, so the description has no parameter burden. It still adds useful context about the parameters and defaults exposed by each report, which helps the agent understand what the output means, but this is not required for invoking the tool.
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?
The description states a specific verb and resource: 'List the BI Publisher reports this server may run.' It also establishes the tool's role as the entry point to every possible query, which clearly distinguishes it from execution tools like fusion_run_report or administrative tools like fusion_author_report.
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?
It explicitly says 'Call this FIRST' and explains that all runnable work is limited to registered reports, so an agent knows to consult this tool before attempting any query. It also gives guidance for the negative case: if no report exists, say so and hand the user the SQL and parameters as a one-time admin task. It does not explicitly name sibling tools to use instead, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: unknown reports/params are rejected before any round trip, omitted parameters silently fall back to stored defaults yielding plausible wrong answers, row caps are applied after rows arrive, and truncated semantics are clarified. This is exactly the kind of non-obvious behavior an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but each paragraph earns its place by covering validation behavior, fallback hazards, and row-count semantics. It is front-loaded with a clear one-line purpose and uses structure well. It could be tightened slightly, but the length is justified by the subtle failure modes it prevents.
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?
Given the output schema already describes the return shape, the description covers everything else an agent needs: how to discover valid inputs, exact validation semantics, dangers of dropped parameters, row-cap behavior, and per-parameter details. No important gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter semantics. It explains each parameter meaningfully: report is a registered name, params are bind values with defaults, max_rows is clamped to the server maximum, and timeout_s is per-call. The included example {'p_pattern': '%INVOICE%'} makes the expected shape concrete.
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?
The first sentence states the exact action: 'Run one registered BI Publisher report with bind values.' This clearly distinguishes it from siblings like fusion_run_query and fusion_adhoc_query, which operate on ad-hoc queries rather than registered reports.
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?
The description explicitly directs the agent to discover valid report names and parameters via fusion_list_reports, and explains when this is the only path to the database. It does not explicitly name alternatives to avoid, but the context strongly implies when to use this tool versus a query tool, so it is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it switches config, credentials, report registry, fixtures, audit log, and docs snapshot; persists until session end or re-call; and alerts that schema knowledge does not carry across pods. This enriches the readOnly/idempotent hints without contradicting them.
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?
The description is tightly structured, front-loading the central behavior in the first sentence, then explaining side effects, caveats, and parameters. Every sentence adds useful information with no filler.
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?
For a session-binding tool, the description is complete: it defines the effect, the lifecycle, the caveat about cross-pod schema knowledge, and the response convention. An output schema exists, so the description need not spell out return values.
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 schema provides only the parameter name 'pod' with no description, so the description carries the full burden. It explains that the value is a directory name under pods/ and gives concrete examples ('test' or 'prod'). This is sufficient for a single simple parameter, though it could have pointed to fusion_list_pods for available values.
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?
The first sentence, 'Bind this session to one pod: every later call runs against it,' clearly states the verb, resource, and immediate consequence. It also distinguishes itself from sibling tools by describing a session-wide context switch rather than a data operation, which is unique among the sibling list.
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?
The description clearly implies when to use the tool: before subsequent calls when a specific pod context is needed. It explains how long the effect lasts and even warns about schema differences across pods. However, it does not explicitly name sibling alternatives like fusion_list_pods for discovering pod names, so the guidance stops just short of fully routing the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, open-world, and non-destructive. The description adds substantial behavior beyond that: every expectation is evaluated without short-circuiting, the diff is a repair signal, common failure modes map to concrete root causes, and cross_check returns as one failed expectation by design. It also discloses the honest limits about ground-truth consistency and service-account visibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the length is justified by the tool's complexity. It front-loads the core purpose, uses bullet lists for failure-mode triage, and ends with a compact Args section. A little trimming of the philosophical framing ('trustworthy rather than merely plausible') would make it tighter, but no sentence is pure filler.
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?
For a validation tool with 6 parameters, no schema-level descriptions, and high behavioral nuance, the description covers everything an agent needs: full parameter semantics, failure interpretation, repair ownership, environment limitations, and the meaning of a passing fixture. The existence of an output schema relieves it of documenting return shapes, and it appropriately leaves expectation object schemas open while giving concrete examples of valid ground-truth sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden—and it pays off. The Args section explains every parameter in plain terms, adds the relationship that expectations and fixture are mutually exclusive, clarifies max_rows is applied locally because the report applies no cap, and notes that omitted params take defaults. This far exceeds what the bare schema offers.
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?
The opening sentence, 'Run a registered report once and check its results against known ground truth,' names a specific verb, resource, and outcome. It further distinguishes itself as 'the validation path that works on a pod without lexical substitution,' separating it from sibling report/validation tools without needing to read their schemas.
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?
The description gives strong context on when to use the tool: supply trusted ground truth and get all failures in one pass. It also explains what cross_check will do in this environment and instructs to vary bind values to test filter tightness before assuming data security issues. It never explicitly names a competing sibling such as fusion_validate_query or fusion_run_report, so it stops short of a full when-to-use-vs-alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining there is no replay guard, that a second attempt fails naturally because the task is no longer ASSIGNED, and that pod state is the duplicate protection. This is rich, honest behavioral disclosure for a destructive, non-idempotent action.
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?
The description is dense but efficient. The warning is front-loaded, the replay-guard explanation is relevant, and the Args section is compact without filler. Every sentence adds necessary operational detail.
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?
For a mutation tool with an output schema, the description covers the decision action, dynamic outcome validation, failure behavior, duplicate protection, and all parameter semantics. Nothing essential for correctly invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameters. It explains each argument: number, outcome with the critical dynamic-value warning, optional comment, and the safety guard on confirmed. This fully compensates for the schema's lack of descriptions.
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?
The description clearly identifies the action: approving, rejecting, or otherwise deciding a task. The emphatic 'THIS DECIDES SOMETHING' and the annotation title 'Submit a decision on a worklist task' make the mutation intent unmistakable and distinct from read-oriented siblings like fusion_task_detail or fusion_list_tasks.
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?
The description gives strong procedural guidance: outcome must come from fusion_task_detail, values differ per task/user, and APPROVE should never be assumed. It does not explicitly discuss alternatives or when-not-to-use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the read-only/idempotent annotations by explaining exactly what is returned, how `writable_only` changes the field set, and documenting that `declared_mandatory` flags are unreliable in both directions on this pod. This is precisely the kind of non-obvious behavioral caveat an agent needs.
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?
The description is compact but information-dense, with the core purpose front-loaded, followed by return-value details, a critical warning, and parameter semantics. Each sentence earns its place; nothing is filler.
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?
Given the output schema exists and annotations cover safety/idempotency, the description covers the essential calling context: how to name the resource, what to expect in the response, and the known data-quality caveats. An agent has enough to invoke this tool correctly and interpret its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates: `resource` is explained with a concrete example, `writable_only` is defined with real field-count numbers, and `limit` is described as the maximum number of fields returned. Every parameter gets meaningful semantic context beyond its raw schema type.
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?
The description states it returns the settable field list for one REST resource, with a clear verb ('returns') and resource scope. It also mentions child collections and required-field guidance, and its mention of 'REST resource' distinguishes it from sibling describe tools like fusion_soap_describe and fusion_describe_table.
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?
It gives strong contextual guidance: 'Read `required_fields` and `required_source` before trusting anything else' and explains when the pod's own message is authoritative versus when flags are unreliable. It does not explicitly name alternatives or say when not to use this tool, but the provided usage context is clear enough for an agent to know it is the input-collection step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive, so the description does not need to restate safety. It adds valuable behavior: the `list_tables` probe strategy, the legacy `SELECT 1` fallback, the `param_shape` auto-detection nuance, and the `degraded` status meaning. This is rich behavioral disclosure.
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?
The description is organized in short, purposeful segments: purpose, probe behavior, status interpretation, then arg documentation. Every sentence carries diagnostic value, and the main purpose is front-loaded.
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?
The description covers behavior, fallback, error semantics, degraded status, and all parameters, while an output schema handles return-value details. Nothing essential for an agent to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all three args: `datasource` as the configured key with error behavior, `report` as a replacement for `list_tables`, and `pattern` as the `p_pattern` bind value. This goes well beyond the bare schema.
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?
The description opens with a precise verb and target: 'Verify the whole path to the pod: credentials, report, bind values, parsing.' It clearly distinguishes this from sibling tools by framing it as an end-to-end probe that runs `list_tables`, unlike direct query/report tools.
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?
The use case is strongly implied: use this to check connectivity, credentials, and report plumbing in one shot, with `status` semantics for interpreting results. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the operation is read-only, idempotent, and non-destructive. The description adds non-obvious behavioral details that annotations cannot convey: file contents are not returned inline because logs can be megabytes, and passing save_to triggers writing files to a directory and returning paths.
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?
The description is tightly organized: a one-line purpose, an explicit when-to-use instruction, a critical behavior warning, and a clean args list. Every sentence carries useful information and the structure is easy to scan.
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?
Given the tool's modest complexity and the presence of an output schema, the description covers everything needed: when to call, what each parameter means, what happens with save_to, and why logs are not inlined. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of semantic meaning for all three parameters. It fully explains request_id, defines the two file_type values ('log' vs 'out'), and clarifies that save_to is an optional output directory with side effects.
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?
The description leads with a specific verb ('Fetch') and a concrete resource ('a finished job's log or output'), and ties it to a clear diagnostic purpose ('WHY it failed'). This distinguishes it sharply from sibling tools like fusion_job_status, which reports job state rather than retrieving logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition: call this whenever fusion_job_status reports ERROR. It also explains why this step is necessary, turning a simple feature description into a decision rule an agent can act on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: 'An unrecognised state counts as still running on purpose' explains a deliberate, safety-oriented behavior. This is exactly the kind of contextual disclosure that helps an agent avoid prematurely abandoning jobs. It aligns with the openWorldHint and readOnlyHint annotations.
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?
The description is compact, front-loaded with the core purpose, and every sentence adds value. The rationale for treating unknown states as running is justified in one clause. The Args section is direct and minimal.
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?
For a single-parameter polling tool, the description covers what matters: what to check, when to stop polling, and how to handle unrecognized states. An output schema exists to describe return fields, so the description does not need to explain return values. The tool is fully usable from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only names 'request_id' with title 'Request Id', providing zero description coverage. The description compensates fully by specifying that request_id is 'The id returned by fusion_submit_job,' which gives the agent the precise origin and meaning of the required parameter.
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?
The description uses a specific verb and resource: 'Check a scheduled process submitted with fusion_submit_job.' It clearly distinguishes this tool as the status/polling counterpart to a job submission tool. The reference to the sibling submit tool anchors its purpose without ambiguity.
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?
The description provides clear usage context: it is for checking a scheduled process after submission, and 'finished tells you whether to stop polling.' It does not explicitly enumerate alternatives or exclusions, but the polling behavior is stated well enough for an agent to decide 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior; the description adds substantial non-obvious details: the report has no intrinsic row cap, `truncated` honestly reveals extra rows, `approx_rows` can be stale/NULL, and echoed `owner`/`pattern` may differ from passed values due to defaults. These disclosures go far beyond the annotations and contradict nothing.
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?
The description opens with a one-sentence summary, then uses tight paragraphs and a bulleted Args section. Every caveat—stale statistics, bound-value echoing, no row cap—is load-bearing for correct use, and there is no filler or tautology.
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?
The description fully equips an agent to select and invoke the tool correctly: result interpretation (`approx_rows`, `truncated`, `params_used`), default-binding behavior, and parameter traps are all addressed. Since an output schema already exists, not restating the full return shape is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility, and it delivers. It explains `pattern` with LIKE syntax and case-insensitivity, `owner` with LIKE-vs-= semantics and default binding, `limit` as a post-report cap, `include_views` as unsupported, and `datasource` as a legacy fallback that is ignored on the report path.
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?
The opening line states a specific verb and resource: 'List Fusion tables matching a SQL LIKE pattern, most-populated first.' This clearly identifies what the tool does and its distinguishing qualifiers, making it easy to separate from sibling list/describe/query tools even without explicit sibling names.
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?
Provides strong operational context: it runs the registered `list_tables` report, applies `limit` after rows arrive, and warns that `approx_rows` is only a stale hint, never a count. It also flags `include_views` as unsupported and `datasource` as legacy-only, but it never explicitly names alternative tools or gives a direct when-to-use vs. when-not-to-use comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral context beyond those: the specific endpoint, the refusal of ANY with an explanation, the absence of outcome data in the list, and the dead-end alternative routes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then provides integration context, usage caveats, and parameter details in a logical order. The list of six 404 routes is somewhat verbose but purposeful because it prevents wasted exploration. Slightly longer than strictly necessary, but every part earns its place.
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?
With only two optional parameters and an output schema present, the description covers everything needed to call the tool correctly: user-scoped worklist, status semantics, limit behavior, invalid ANY handling, and the important caveat to follow up with fusion_task_detail. The output schema handles return-value documentation, so nothing essential 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?
Schema description coverage is 0%, so the description must compensate. It does: status is explained as the service's own status values with ASSIGNED as an example and ANY explicitly excluded, while limit is defined as maximum tasks returned. This is sufficient for correct invocation, though enumerating valid status values would have been even stronger.
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?
The description opens with 'Approvals and notifications waiting for the signed-in user,' which clearly identifies what the tool returns and for whom. It also distinguishes this tool by naming its dedicated endpoint as a 'third channel' and explicitly points to fusion_task_detail as a separate follow-up tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool: to see approvals/notifications for the signed-in user. It also gives explicit follow-up guidance—call fusion_task_detail before acting because outcomes are not included—and warns that status ANY is rejected. The note that six plausible routes answer 404 helps prevent the agent from trying wrong alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructive/read-only annotations, the description discloses the envelope is built from the service contract with service-specific namespaces, parameters are sent in contract order, omitted parameters become empty elements shifting positional arguments, and read-only operations still pass through the destructive gate. This is substantial behavioral context that annotations alone do not provide.
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?
The warning about data change is front-loaded, each paragraph adds unique behavioral or safety information, and the Args list is compact. The namespace discussion is a little detailed but earns its place because it explains a real failure mode.
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?
For a complex mutating tool, the description covers prerequisites, parameter behavior, safety gate, and service-specific envelope construction. An output schema exists, so return-value documentation is not required from the description, and nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section explains every parameter: service gets a concrete path example, operation is sourced from fusion_soap_describe, parameters is a name/value map with ordering and omission semantics, and confirmed has a strict safety condition. This fully compensates for the schema's lack of descriptions.
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?
The description opens with a specific verb and resource: 'Invoke any snapshotted SOAP operation.' It also references fusion_soap_describe for operation names and explicitly warns it may change data, making it easy to distinguish from sibling inspection tools such as fusion_soap_describe and fusion_soap_list_services.
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?
It provides a clear prerequisite—operation names must come from fusion_soap_describe—and states that confirmed must only be set after explicit user confirmation. It does not explicitly enumerate alternative tools or when-not-to-use conditions, but the scope ('any snapshotted SOAP operation') and the destructive gate make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: the list is observed rather than declared, fields come from the pod's own rejection messages, and a concrete 403 example explains why some advertised resources are absent. It also clarifies the semantics of missing resources, which is critical for correct interpretation. No contradiction with the readOnlyHint/openWorldHint/idempotentHint annotations.
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?
The description is information-dense but every sentence earns its place: the core purpose, the entry-point instruction, the observed-vs-declared distinction, and the missing-resource fallback. The example with purchaseOrders is specific and memorable without being bloated.
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?
Given there are no parameters and an output schema exists, the description supplies all necessary operational context: what the list contains, where the data comes from, how absence should be interpreted, and what to do next. It fully equips an agent to decide when and how to use this tool correctly.
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 has zero parameters and the input schema is empty, so there is no parameter meaning for the description to add. Per the baseline for zero-parameter tools, this is fully adequate.
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?
The first sentence states exactly what the tool does: list what the service account was observed able to create on the pod. It differentiates observed capabilities from declared ones and distinguishes this from sibling tools like fusion_api_describe by emphasizing this is harvested from rejection messages, not metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Start every "register a X" request here,' giving a clear when-to-use instruction. It also provides an alternative path: if a resource is missing, check with fusion_api_describe, which reports write_access either way. This gives the agent actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it explains the pod directory structure, the presence of config.yaml and an .env credentials file, the active-pod concept, and the specific behavior when no pods/ directory exists. This goes well beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose, and the following sentences add only high-value context about pod structure, session flow, and the no-pods edge case. Every sentence earns its place.
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?
Given zero parameters and a rich output schema, the description fully covers what an agent needs to call this tool correctly: why to call it, when to call it, what it returns, and how to interpret an empty listing. No important operational context 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 has zero parameters, and the schema coverage is effectively complete. The description adds no parameter-specific details, but none are needed. Baseline 4 is appropriate for a parameterless tool where there is nothing to clarify beyond the schema.
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?
Description uses a specific verb and resource ('list' and 'Fusion pods'), and clearly states the tool's output: which pods the server can talk to and which one is active. It is clearly distinguishable from siblings like fusion_use_pod because it explicitly frames listing as the precursor to a session-binding action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call this at the start of a session, then fusion_use_pod to bind the session to one pod.' It also covers the single-config mode edge case, telling the agent when this tool will list nothing, which prevents misinterpretation of an empty result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (which already mark destructiveHint=true). It discloses irreversibility: 'A submitted job CANNOT be recalled.' It also reveals that even a failed attempt has side effects: 'once the request id exists the job is queued.' This adds crucial context about real-world consequences not captured by the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not bloated. It front-loads the most critical warning ('THIS STARTS REAL WORK'), then provides scope, return behavior, irreversibility, and parameter guidance. The quoted pod wording adds length but is unique and valuable. A slightly tighter phrasing around the REST create comparison could make it more concise, but every sentence contributes meaning.
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?
This is a high-complexity tool with an output schema available, so return-value explanation is not needed. The description covers the operational essentials: when it applies, how to confirm, what to expect (request id), how parameters must be ordered, and irreversibility. There are no significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explains each of the four parameters in the Args section, including examples for `package` and `definition`, and provides detailed positional semantics for `parameters` with the explicit instruction to use empty strings for skipped arguments. It also explains the `confirmed` flag. No parameter is left unexplained.
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?
Description opens with a specific verb and resource: 'Run a Fusion scheduled process (ESS job).' It explicitly distinguishes itself from REST-based operations by saying 'For everything that has no REST resource: Import Payables Invoices, Create Accounting, and the rest of Scheduled Processes.' This clearly separates it from sibling tools like fusion_run_query or fusion_run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'For everything that has no REST resource' and lists concrete example jobs. It also tells the agent to poll with `fusion_job_status` for results. It additionally gives a strong when-not-to-use signal: unlike a REST create, a submitted job cannot be safely failed, so user confirmation is required before setting `confirmed`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reveals significant behavior beyond annotations: ephemeral catalog report creation/deletion, parameter-echo verification, audit with real SQL, config gate, and a cost note of two uploads plus two deletes per call. Annotations already mark it read-only/idempotent/non-destructive, and the description enriches that with implementation-level detail without contradicting it.
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?
Long but every sentence earns its place; complex constraints are formatted as scannable bullets, and the critical 'one ad-hoc SELECT' is front-loaded. The cost/alternative guidance is concise but not extraneous.
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?
Given the tool's complexity, this is complete: usage constraints, parameter behavior, security/audit implications, performance cost, and routing to the persistent-report sibling are all present. An output schema exists, so not describing return values is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section fully compensates: each of the five parameters gets beyond-schema meaning (aliasing rule for sql, no defaults for binds, fallback role for columns, clamping for max_rows, units for timeout_s).
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?
Description opens with a specific verb-resource pair: 'Run one ad-hoc SELECT by authoring an ephemeral report for it.' It goes on to distinguish the tool from persistent reports by explaining the SQL is turned into a transient report rather than run through a fixed one, which separates it from fusion_run_query/fusion_run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it (one-off ad-hoc SELECT) and when not to: 'If the same shape of question will be asked again, mint it once with fusion_author_report and run it as a registered report from then on.' It also prescribes exploration workflow and hints at config gating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors beyond annotations: the report is persisted under /Custom/MCP/, registered in a dynamic registry file rather than config.yaml, gated behind a config flag, and verified through a normal pipeline before registration. It also clarifies that force only overwrites reports created by this tool and never touches pre-existing config.yaml entries, which fully informs the agent of side effects.
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?
Although detailed, every sentence serves a clear purpose: purpose, when-to-use, SQL rules, description guidance, verification recommendation, gating, and overwrite semantics. The content is logically organized and front-loaded with the core purpose, making it easy for an agent to parse quickly.
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?
Given the tool's complexity and an existing output schema, the description covers all operational context: prerequisites, configuration gating, failure behavior, parameter meaning, verification, and overwrite rules. An agent has everything needed to call this tool correctly and avoid common mistakes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden, and it succeeds by explaining every parameter: name's naming convention, sql's SELECT and bind rules, description's purpose for the next agent, defaults' role, verify_binds' verification run, and force's overwrite scope. This goes far beyond the bare type information in the schema.
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?
The description opens with a precise verb and resource: 'Mint a PERSISTENT report from SQL and register it for future runs.' It clearly distinguishes this tool from the sibling fusion_adhoc_query by contrasting one-time query cost vs. reusable registered reports, so an agent can select it without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'Use this when a question will be asked again,' and contrasts it with ad-hoc queries that cost catalog round trips. It also names related run/validate tools and notes that the report is immediately runnable via fusion_run_report / fusion_validate_report, giving clear guidance on the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior far beyond the annotations: it is safe to call twice, existing catalog objects are skipped and never replaced or deleted, replacement requires a human decision via a shell command, and each new report is echo-checked with a failure mode of being left in the catalog but not registered. This is rich, actionable context not available from readOnlyHint, destructiveHint, or idempotentHint.
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?
The description is dense but every sentence earns its place: purpose, trigger conditions, scope boundaries, safety/idempotency, failure semantics, and parameter explanations are each clearly separated. The first sentence front-loads the core purpose, and the Args section is tight and scannable.
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?
For a complex bootstrap tool with 3 parameters, no required fields, and an output schema already present, the description covers all necessary context: when to call it, what it does not do, side effects, failure handling, and parameter defaults. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining all three parameters. It does so thoroughly: 'only' is shown with an example and default behavior ('all four'), 'folder' is given a purpose and default, and 'data_source' is explained with pod-specific guidance and an example ('ApplicationDB_HCM'). This compensates fully for the empty schema descriptions.
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?
The description opens with a specific verb and resource: 'Create the exploration reports this pod is missing, from shipped SQL.' It explicitly names the affected sibling tools (fusion_list_tables, fusion_describe_table, fusion_search_columns, fusion_describe_flexfields) and differentiates itself from fusion_author_report, so an agent can identify its role without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger condition: 'Call this when fusion_list_tables / fusion_describe_table / fusion_search_columns / fusion_describe_flexfields fail on a pod that is otherwise healthy.' It also states a clear exclusion: a passing fusion_health_check does NOT cover this, and it contrasts itself with fusion_author_report, giving unambiguous routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), it discloses that the token is single-use and that a refusal returns the pod's message and named fields rather than a normal summary. This materially changes how the agent should handle the response and subsequent user interaction.
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?
The description is compact and front-loaded with a clear safety warning. The prose and Args section reinforce the critical confirmation requirement with minimal redundancy and no filler.
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?
It covers the token lifecycle, the confirmation requirement, direct edit behavior, single-use semantics, and refusal behavior. Since an output schema exists, not listing return fields is acceptable; the description is complete enough for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for both parameters. It clearly defines token as coming from fusion_prepare_action and confirmed as only set after explicit user confirmation, adding meaning the schema's titles and default value do not provide.
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?
The description uses a specific verb and resource: 'Execute a prepared action,' and immediately signals that it changes data. It also distinguishes itself from fusion_prepare_action by referencing the token required from that prepare step, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exact preconditions: a token from fusion_prepare_action and confirmed=True only after the user has seen the preview and said yes. It also explains the failure path—a refused attempt needs a fresh prepare—so the agent knows when to go back to the sibling tool instead of retrying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses internal behavior beyond annotations: it reads fnd_df_segments_b/_tl, returns segment rows with COLUMN_NAME and CONTEXT_CODE, and clarifies that 'Context Data Element' rows describe the context chooser rather than data segments. It also gives practical semantics for SEGMENT_PROMPT and global vs. context-specific segments. Annotations already mark it read-only and idempotent, and nothing contradicts them.
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?
Though long, the description is densely informative with no filler. It front-loads the core question, provides a clear numbered protocol, includes concrete examples, and adds necessary caveats about context rows and prompt labels. Every sentence contributes operational value.
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?
For a metadata-introspection tool, the description covers the full workflow: schema discovery, DFF code guessing, LIKE-pattern fallback, query construction, and context filtering. It explains return-relevant fields such as COLUMN_NAME, SEGMENT_CODE, CONTEXT_CODE, and SEGMENT_PROMPT, and the output schema removes the need to enumerate return structure. The limit parameter and its default are also addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It explicitly documents all three parameters: flexfield as a case-insensitive LIKE pattern with examples, context as an optional LIKE pattern over CONTEXT_CODE, and limit as a maximum row count. This fully compensates for the schema's lack of descriptions.
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?
The opening line states exactly what the tool does: maps DFF segments to the ATTRIBUTEn column that stores each one. It distinguishes itself from siblings like fusion_describe_table by explaining that this reads the DFF definition rather than the base table structure, and the protocol explicitly sequences the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Protocol for an unknown table' section gives concrete when-to-use guidance: first describe the base table, then call this tool with the DFF code or a LIKE pattern, then project the returned column in an adhoc query. It also explains how to handle uncertain DFF codes and context-specific segments, which is exactly the kind of decision support an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readonly, open-world, idempotent, and non-destructive, and the description adds meaningful behavioral context beyond them: it uses a docs-derived snapshot rather than pod ground truth, returns not_found rather than silently succeeding, and reveals timing characteristics. This helps the agent reason about correctness and failure modes.
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?
The description is well-structured and front-loaded: purpose, differentiation, caveats, then parameter details. Despite being detailed, every sentence earns its place, and the formatting makes the key decision points and argument semantics easy to scan.
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?
Given the output schema exists and the tool is documented as a read-only snapshot lookup, the description sufficiently covers return contents, limits, fallback behavior, and parameter semantics. Nothing an agent needs to call this tool successfully is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully carries parameter documentation. It explains that table is an exact table/view name with an example, that columns_like is a case-insensitive substring filter on column name or description, and that limit caps the number of returned column entries. This is exactly what an agent needs beyond the raw schema.
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?
The description opens with a specific verb and resource: 'Describe a table from the local Oracle-docs snapshot'. It clearly enumerates what the tool returns (column business descriptions, primary key, foreign keys, indexes, flexfield mappings, view SQL) and explicitly contrasts itself with fusion_describe_table, so an agent can distinguish it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Prefer this over fusion_describe_table for exploration' and explains why by comparing performance and semantic richness. It also provides fallback instructions: when the snapshot returns not_found, use the live tools because custom objects and case-twin duplicates exist only on the pod.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds valuable behavior beyond that: it searches a local snapshot, matches both column names and descriptions, combines words with AND, and warns that live-pod existence verification is needed before execution.
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?
The description is well-structured and front-loaded with the core purpose. The example, caveat, and argument explanations all earn their place without excessive verbosity. It remains tightly scannable while conveying meaning.
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?
Given the output schema and annotations, the description covers everything necessary: source of data, matching semantics, parameter meanings, and a key caveat about verifying existence on the live pod. There are no material gaps for an agent to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although input schema description coverage is 0%, the description fully compensates by explaining both parameters: term as AND-combined words or a column-name fragment, and limit as the maximum number of matches returned. This is exactly the semantic detail an agent needs.
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?
The description states a specific action and resource: searching columns across ALL documented tables by name or business meaning. It is clearly differentiated from the live sibling tool fusion_search_columns by emphasizing the local docs snapshot and discovery-focused use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs when to use this tool: prefer it over fusion_search_columns for discovery and then verify existence on the pod when executing. It also gives a concrete example of search intent, making the usage context unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the destructiveHint annotation by stating that the operation loads real data, cannot be recalled, uploads to UCM, and queues jobs in order. It also discloses a subtle failure mode where a wrong account uploads successfully but becomes invisible to the import job with no error.
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?
The description is detailed but every sentence adds operational value, and the most critical warning (loads real data, cannot be recalled) is front-loaded. The parameter explanations are structured and directly map to the schema properties without 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?
For a destructive bulk-import tool with no schema-level parameter descriptions, this covers all necessary context: the data flow, the job format, ordering, confirmation requirement, and the key failure mode. Having an output schema makes the lack of return-value detail acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the full burden, and it does: file_path is the local path, account is the UCM account with an example, jobs are described as ordered entries with a concrete structure, notification_code is the two-digit code, and confirmed is gated on user confirmation.
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?
The description opens with a specific action: load a data file into Fusion (FBDI) and queue import jobs. It clearly distinguishes itself from related tools like fusion_submit_job by explaining the comma-joining behavior and bulk-import focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool versus fusion_submit_job, including the exact condition (parameters containing commas) that should route the agent to the alternative. Also instructs that `confirmed` must only be set after explicit user confirmation, and warns about the quiet account mismatch failure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, the description adds essential behavioral context: no payload is sent, a validation token is produced, and Fusion applies no confirmation pause. It also warns that prepare does not guarantee success and is not a dry-run. This goes far beyond what the annotations alone convey.
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?
The description is front-loaded with the most critical fact ('Sends NOTHING to the pod') and every sentence earns its place by adding either workflow, limitation, or parameter semantics. The structure moves from behavior to workflow to caveats to arguments, making it easy for an agent to parse. It is longer than minimal, but the length is justified by the safety-critical nature of the tool.
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?
The description is complete for a safe-preview tool of this complexity: it covers behavior, outputs, workflow, limitations, and parameter semantics, and it references the output schema rather than duplicating return details. It also explains why this tool exists given Fusion's lack of a confirmation pause. Nothing an agent needs 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the full burden and does so well. It explains resource with an example and how to discover valid values, payload with an id-resolution prerequisite, verb with POST/PATCH semantics, and record_id as required for PATCH. Every parameter gains meaning beyond its schema title or default.
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?
The description states a specific verb and resource: it checks an action and holds it for confirmation, explicitly saying it sends nothing to the pod. It also distinguishes itself from fusion_commit_action by explaining that the action only reaches Fusion when that sibling presents the returned token. This is exactly what an agent needs to tell this tool apart from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use guidance: show the preview to the user, get explicit yes, then commit via fusion_commit_action. It also names supporting siblings (fusion_api_list_actions for valid resources, fusion_resolve_value for ids) and explains what the tool cannot do, preventing misuse as a dry-run. This is explicit workflow-level guidance, not just a vague hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the tool runs as a normal guarded SELECT on the read channel and is audited like any other query. It also explains the four-outcome model and emphasizes the ambiguous case where candidates are returned for the user to choose. This is rich, non-obvious behavioral context that aligns with readOnlyHint and idempotentHint.
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?
The description is front-loaded with a crisp one-line purpose, followed by a useful example, an explicit invocation rule, a rationale, and an important ambiguity warning. Every sentence earns its place, and the argument list is concise and directly tied to the schema.
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?
For a two-parameter resolution tool, the description covers when to use it, how to pass parameters, matching behavior, ambiguous-result handling, and safety/auditing context. The output schema can carry the exact return-value details, so nothing critical is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, but the description fully defines both parameters: field is the REST attribute name with a concrete example, and text is what the user said with matching semantics ('case-insensitively as a substring'). This completely compensates for the bare schema.
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?
The description states a specific transformation: 'Turn a name the user said into the id the API wants,' and gives a concrete example mapping RequisitioningBUId to 'the Egypt BU'. It also explicitly instructs when to invoke it ('Call this for every id-shaped field before putting it in a payload'), making it clearly distinguishable from sibling tools like fusion_run_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use rule: call this for every id-shaped field before building a payload. It also explains why direct alternatives fail ('all candidate paths answer HTTP 404') and warns the agent never to pick an ambiguous match itself, which is essential decision-making guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses critical failure behavior: lexical substitution may be silently disabled, the statement could become `SELECT * FROM ()`, and no SQL rewrite fixes it. It also reveals that the tool appends a row cap, rejects anything not a single SELECT/WITH, and can produce unparsable XML output if expressions lack aliases.
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?
The description is long but every section earns its place: a front-loaded warning, a clear alternative path, a precise scope statement, and a compact parameter list. It is structured with bolded warnings and separators that make the critical information easy to scan.
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?
Given the tool's complexity, zero schema coverage, and a non-obvious failure mode, the description covers everything needed to invoke it correctly: prerequisites, failure signature, workaround path, SQL constraints, row-cap behavior, alias rules, and per-parameter semantics. An output schema exists, so not detailing return values is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility, and it delivers. It explains all 9 parameters in the Args list, including the engine_mode clause-building parameters, the meaning of max_rows clamping, timeout_s, and datasource defaulting, plus the alias requirement for selected expressions.
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?
The description clearly states a specific verb and resource: 'Run a read-only SQL SELECT -- ONLY on a pod that substitutes lexical parameters.' It distinguishes this tool from the report-registry path and explicitly frames it as the 'full free-SQL surface,' making its identity unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance: check whether the pod honors lexical parameters, avoid a repair loop if the ORA-00903 signature appears, and instead use fusion_list_reports followed by fusion_run_report and fusion_validate_report. This directly names alternatives and the condition that selects them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false, but the description adds crucial behavioral context: passing the wrong load_request_id lands the correction on a different batch, and the tool must not be confirmed until the user reads back the request ID. This warns about the destructive, mis-targeting risk and the confirmation requirement beyond what annotations state.
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?
The description is front-loaded with a one-sentence summary, followed by a concrete illustrative scenario, a crucial warning, and a terse Args list. Every sentence carries operational value; the example scales the problem ('ten thousand rows, forty rejected') without bloating. No filler or repetition.
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?
With five parameters, zero schema descriptions, a destructive annotation, and an output schema present, the description covers everything needed for correct invocation: all parameter meanings, the confirmation protocol, and the risk of using the wrong load_request_id. It leaves no essential gap for the agent to call or validate this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so every parameter must be explained in the description. It does so clearly: process_name, load_request_id, file_path, account, and confirmed all receive meaningful definitions. The warning about load_request_id adds critical semantic nuance beyond the mere schema name.
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?
The description opens with 'Replace the rejected rows of a partly-failed import with corrected ones,' a specific verb-resource pair that clearly states what the tool does. It distinguishes itself from broader import/submission siblings by focusing on the repair of rejected rows, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the repair path: an import with forty rejected rows is corrected by replacing those rows 'rather than reloading the whole file.' This contrasts with the alternative and tells the agent when to invoke this tool. It also gives a safety guideline: verify the load_request_id and require explicit user confirmation before confirming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive, and the description adds substantial behavior: the lexical-substitution failure mode with ORA-00903, all expectations always evaluated, diff interpretation, join fan-out, and row-level security visibility. It also discloses the limitation that passing only proves consistency with supplied ground truth.
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?
The description is dense but front-loaded, with the core purpose and key constraint in the first line. Each paragraph earns its place, and the final Args bullet list gives a scannable parameter reference without padding.
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?
Given the tool's complexity, the description covers when to use it, failure modes, diagnostic interpretation, and limitations. An output schema exists for response details, so the description's focus on selection and interpretation is appropriately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no property descriptions (0% coverage), but the Args section explains every parameter, including mutual exclusivity of expectations and fixture, the meaning of datasource as a configured key, max_rows as a cap above expected count, and timeout_s as per-call timeout. This fully compensates for the schema gap.
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?
The description opens with a specific verb and resource, 'Validate free SQL', and immediately differentiates itself from fusion_validate_report ('same engine... pointed at a statement instead of a registered report'). It clearly establishes this tool validates ad hoc SQL rather than registered reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit condition for use ('ONLY on a pod that substitutes lexical parameters') and names the alternative ('Use fusion_validate_report instead there'). It also explains when the tool applies ('Where free SQL does run') and how to distinguish failure modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Fusion-MCP MCP server](https://glama.ai/mcp/servers/ruya-grp/Fusion-MCP/badges/card.svg)](https://glama.ai/mcp/servers/ruya-grp/Fusion-MCP)

Score Badge

Copy to your README.md:

[![Fusion-MCP MCP server](https://glama.ai/mcp/servers/ruya-grp/Fusion-MCP/badges/score.svg)](https://glama.ai/mcp/servers/ruya-grp/Fusion-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ruya-grp/Fusion-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server