FutureSmart AI Demos

get_ranking

Full ranking detail as a JSON+Markdown envelope: ranked tools (rank/badge/scores), criteria, winner, breakdown (JSON) + verdicts / final take (Markdown). Every ranked tool carries proof: real artifact URLs from the exact evidence run this page is bound to, each with the /evidence permalink for the finding it proves — verdict and proof arrive together, no second call needed to cite evidence. proof.artifact_count is the true total and proof.all_findings is the get_evidence call that returns all of it. null if unknown. Pass fields to project to only the keys you need (token-efficient).

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	Yes	Ranking slug, e.g. "resume-parsing-api" (from list_rankings).
`proof`	No	How many proof artifacts to inline. "sample" (default) = up to 6 per tool, spread across distinct criteria so you see breadth; "full" = every artifact; "none" = counts only, no URLs. Counts (artifact_count / finding_count) are the TRUE totals in every mode, so you can always tell what you did not receive.
`fields`	No	Optional projection: return ONLY these top-level fields (identity id/name/title/slug/url is always included) to control response size. Available: id, title, slug, url, abstract, read_time, tested_date, category, use_case, personas, tags, winner, methodology, tools, breakdown, final_take, evidence_run.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly. It discloses the response format, proof behavior (sample/full/none), that counts are true totals in every mode, and null fallback. It also explains the fields projection for token efficiency, leaving little ambiguity about tool 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 the main purpose and is dense with useful details. The proof explanation is lengthy but each sentence contributes value. It could be slightly tighter, but it remains well-structured and efficient.

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?

Without an output schema, the description compensates by explaining the JSON+Markdown envelope, proof artifact behavior, true totals, and fields projection. For a tool with 3 parameters and nested proof structure, this is complete enough for an agent to invoke correctly.

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

Parameters3/5

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

Schema coverage is 100% with detailed parameter descriptions for slug, proof, and fields. The description adds only a token-efficiency tip for fields, which is a usage suggestion rather than new semantic meaning. Thus, baseline 3 is appropriate.

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 the tool returns "Full ranking detail as a JSON+Markdown envelope" with ranked tools, criteria, winner, breakdown, and verdicts. It distinguishes from siblings by detailing that each ranked tool carries proof with artifact URLs and evidence permalinks, which is unique to this tool.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool: when you need full ranking detail with evidence. It also hints at an alternative by saying "no second call needed to cite evidence," implying you can skip get_evidence. However, it does not explicitly compare to similar tools like list_rankings or tools_in_ranking.

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

All FutureSmart AI Demos tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation5/5

Every tool targets a distinct entity or action: list tools enumerate different content types, get tools retrieve specific entities, search finds across the catalogue, compare_tools does head-to-head comparison, and the two cross-reference tools (rankings_for_tool and tools_in_ranking) are inverse operations. No two tools have overlapping purposes.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (list_*, get_*, compare_tools, search), but 'rankings_for_tool' and 'tools_in_ranking' deviate with a noun_prep_noun pattern. These two are internally consistent with each other and remain readable, so the overall convention is only slightly disrupted.

Tool Count4/5

16 tools is slightly above the ideal 3-15 range but still well-scoped for a catalogue covering seven entity types, search, comparison, and cross-references. Each tool has a distinct role and none are redundant, so the count feels justified rather than bloated.

Completeness4/5

The tool surface covers all major content types with list and get (except categories and toolkits, which only have list endpoints), plus search, comparison, and inverse cross-references. Minor gaps like missing get_toolkit or get_category are workaround-able since list_toolkits and list_categories expose sufficient metadata.

Resources

Need Help?