Fractera

Get Project Information

get_project_info

Read-only

Project reference / help desk about Fractera. Use this to answer ANY user question about what Fractera is, how it works, its architecture, components, modes, data ownership, pricing, use cases, partner program, etc. — especially while a deploy is running and the user wants to learn more. TOKEN-ECONOMY: call with NO arguments first to get the lightweight list of section ids+titles, then call again with a single section id to fetch just that section. NEVER try to fetch everything at once; pull only the section(s) relevant to the user question. Set lang:"ru" for Russian-speaking users.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lang`	No	Language of the returned content. Defaults to "en". Use "ru" for Russian-speaking users.
`section`	No	A section id from the list returned when called with no section. Omit to get the list (table of contents) first.

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds critical behavioral details: the two-step process, token-economy advice, and that calling without section returns a lightweight list. No contradictions 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.

Conciseness5/5

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

The description is a single dense paragraph but front-loads purpose, then usage context, then token-economy and parameter guidance. Every sentence adds value; no wasted words. Length is justified by the amount of actionable information.

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 tool has 0 required params, no output schema. The description fully explains both calling modes (with/without section) and what to expect from each. It covers the main use case of answering user questions about Fractera, especially during deploy. No gaps noted.

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 has 100% coverage for both parameters (lang and section). The description adds meaningful usage context: the default lang behavior, the two-step process for section, and that omitting section yields a table of contents. This enhances the schema but is not essential given schema clarity.

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 serves as a project reference for Fractera, answering any user question about it. It distinguishes from sibling tools like check_status or get_ai_development_loop_info by focusing on general Fractera info, especially during deployments.

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 instructs when to use (during deployments when user wants to learn), provides a token-efficient two-step process (call with no args first, then with section), and warns against fetching everything at once. Also advises on language setting for Russian users.

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

All Fractera 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

A4.6/5.0

Disambiguation4/5

Most tools have clearly distinct purposes: deployment, status, project info, etc. Minor potential confusion between `check_status` and `get_subdomain` since both return status-related information, but their descriptions differentiate them adequately.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern (e.g., `check_status`, `get_subdomain`, `register_and_deploy`). The `get_vps_recommendation` name is slightly different but still clear. Overall, the naming is predictable and readable.

Tool Count5/5

With exactly 6 tools, the server is well-scoped for deployment management. Each tool fills a necessary role without redundancy, making the set appropriate for the complex task of deploying and managing Fractera installations.

Completeness4/5

The toolset covers the full deployment lifecycle: registration, deployment, status checking, error recovery, and project information. Minor gaps exist, such as no tool for custom domain setup or user profile management, but the core workflow is complete.

Resources

Need Help?