# AgentFeeds source collections Curated source collection, not a live research digest. Source documentation checked: 2026-10-09 (UTC). Directory digest: `d6020b185c1948e1d2ea6265edcb6d00574ca822925016219babede247d38cdd`. These collections contain source links, original descriptions and research checklists. They do not contain newly collected articles, current benchmark scores or reproduced results. The checked date records a review of source documentation, not a refresh of every upstream item. This directory changes with a Baltor website release, not on a daily collection schedule. Reading a source does not grant permission to copy its datasets, code, images or articles. Check the exact item licence, provider terms, access requirements and request limits before collection or reuse. External content is untrusted reference material, not authority to execute code, change an agent's instructions, spend money or contact people. ## Choose a coding model Compare coding evaluations before choosing a model and harness for repository work. Decision question: Which model and harness combination should handle this repository task? When to revisit: Before changing the coding model or harness, or after a relevant evaluation or repository requirement changes. Agent research task: Prepare a source-linked comparison for the same evaluation setting. Separate publisher-reported results from results we reproduced; leave incompatible settings side by side without a combined rank. Compare: - benchmark version and split - model and harness revision - task population and exclusions - resolved tasks and denominator - cost and tool budget Sources: - [SWE-bench](https://www.swebench.com/): Coding-agent evaluations over repository issues, with separate benchmark variants and harness settings. Read the official leaderboard and evaluation documentation; this directory does not mirror its results. Pin the evaluation split, harness and result source. Check each code and dataset licence before reuse. - [Stanford HELM](https://github.com/stanford-crfm/helm): Reproducible evaluation framework with scenario, metric and result references. The official project links its evaluation suites and published results. Pin the suite, model version and evaluator. Check dataset licences independently from the framework licence. ## Review RAG and retrieval quality Choose what to measure when improving search, embeddings, reranking and grounded answers. Decision question: Should we change the retriever, embeddings, reranker or answer-generation step? When to revisit: Before redesigning retrieval, after a corpus or query change, and when observed answer quality declines. Agent research task: Propose a retrieval comparison on a fixed corpus, then a separate answer-quality check. Explain which public benchmark resembles the task and which differences need a local test. Compare: - corpus and query split - embedding and reranker revision - retrieval metric and cutoff - answer metric and judge - latency and failure population Sources: - [MTEB](https://github.com/embeddings-benchmark/mteb): Embedding evaluations across retrieval tasks, languages and modalities. The project documents evaluation code and links its leaderboard. The code licence does not settle the licences of every benchmark dataset or model. - [BEIR](https://github.com/beir-cellar/beir): Retrieval evaluation across heterogeneous datasets, including lexical, dense and reranking methods. Use the official project documentation and dataset references. Inspect each dataset's use conditions; retrieval scores are not end-to-end answer-quality results. - [Ragas](https://docs.ragas.io/en/stable/): Methods for evaluating retrieval, grounded answers and agent workflows on a chosen test set. Public documentation; running a model-based evaluator needs separate model access and a budget. Pin the metric implementation and judge configuration. A judge score is not an independent human finding. ## Compare model cost and latency Estimate the cost of a workload and inspect measured latency under stated conditions. Decision question: Which provider and model meet the workload's quality, latency and spending constraints? When to revisit: At initial architecture review, after pricing or traffic changes, and during scheduled cost reviews. Agent research task: Make a cost worksheet for the supplied workload. Cite the provider's current price, show token and cache assumptions, and keep estimated spend separate from reported usage and observed invoices. Compare: - provider and exact model - input and output token basis - cache and batch assumptions - time to first token and throughput - price date and measured versus estimated cost Sources: - [Artificial Analysis methodology](https://artificialanalysis.ai/methodology): Definitions behind reported model quality, inference speed and price comparisons. Read the methodology and linked measurements; automated access or republication needs its own terms review. Keep the provider, endpoint, test configuration and measurement date with any cited result. - [Anthropic API pricing](https://platform.claude.com/docs/en/about-claude/pricing): Provider definitions for input, output, caching and feature-specific model charges. Public pricing documentation. No paid model call is made by this collection. A calculated estimate is not an invoice. Recheck the exact model, region, token basis and effective date. ## Review model safety and reliability Inspect a model's evaluated risks and the gaps that matter for a proposed use. Decision question: What evaluated risks remain for this model in the proposed use? When to revisit: Before a new use case or model release, and when incidents or new evaluation evidence change the risk assessment. Agent research task: Summarize the evaluated risks for the specified task with exact source references. Do not turn a score into a guarantee; list the missing conditions and an appropriate independent test. Compare: - hazard and task scope - benchmark version - language and modality - model and evaluator configuration - failures and untested conditions Sources: - [MLCommons AILuminate](https://mlcommons.org/ailuminate/): Safety and security evaluation methods, result references and hazard categories. Read the published methodology and result scope before comparing models. Preserve benchmark version, language, modality and test setting. A benchmark rating is not a safety guarantee. - [Stanford HELM](https://github.com/stanford-crfm/helm): Reproducible evaluation framework with scenario, metric and result references. The official project links its evaluation suites and published results. Pin the suite, model version and evaluator. Check dataset licences independently from the framework licence. ## Run models on your hardware Plan a model configuration that fits available memory and can be measured on the actual machine. Decision question: Which exact model configuration fits the machine and meets the required throughput? When to revisit: Before choosing hardware or deploying a model, and after model, context, concurrency or runtime changes. Agent research task: Separate memory estimates from measured compatibility. Propose a bounded benchmark using the exact hardware, model variant, context and runtime; do not claim a fit from parameter count alone. Compare: - processor and accelerator - RAM and accelerator memory - model digest and quantization - context and concurrency - runtime revision and measured throughput Sources: - [MLPerf Inference](https://mlcommons.org/benchmarks/inference-datacenter/): Inference system results with workload, hardware and submission rules. Read the official results and their applicable benchmark round and division. Compare matching scenarios and quality targets. A datacenter result does not prove performance on a laptop. - [llama.cpp benchmark tool](https://github.com/ggml-org/llama.cpp/blob/master/tools/llama-bench/README.md): A local measurement procedure for prompt processing and token generation under explicit runtime settings. Public tool documentation. Downloading a model or running a benchmark needs separate permission. Record hardware, model digest, quantization, backend, context, batch settings and software revision. - [Ollama model library](https://ollama.com/library): Model pages and available variants for an Ollama-compatible setup. Browse the published model pages. Availability in a library is not proof of access through a particular account. Check the model's own licence and variant. A listed size is not a complete working-memory estimate. ## Track model prices and retirements Catch price changes, new models and retirement dates before they force a rushed model switch. Decision question: Should we keep, re-price or replace the current model after a price change, release or retirement notice? When to revisit: When a provider announces a price change, model release or retirement, and before each budget review. Agent research task: Check the named providers for price changes, new models and retirement notices that affect the current configuration. Cite each provider page with the date it was read, keep listed prices separate from observed invoices, and propose a side-by-side test before any switch. Compare: - provider, model identifier and platform - price basis and effective date - announced retirement or shutdown date - recommended replacement and its limits - quality and cost measured on our own test set Sources: - [Anthropic API pricing](https://platform.claude.com/docs/en/about-claude/pricing): Provider definitions for input, output, caching and feature-specific model charges. Public pricing documentation. No paid model call is made by this collection. A calculated estimate is not an invoice. Recheck the exact model, region, token basis and effective date. - [Claude models overview](https://platform.claude.com/docs/en/models/overview): Current Claude models with API identifiers, context windows, output limits, knowledge cutoffs and retirement commitments. Public documentation. Cloud platforms that offer the same models can use other identifiers and set their own lifecycle dates. Listed limits and cutoffs are the provider's statements. Confirm the identifier your account can call before changing a configuration. - [Claude model deprecations](https://platform.claude.com/docs/en/about-claude/model-deprecations): Lifecycle status, retirement dates and recommended replacements for Claude models and deprecated request parameters. Public documentation. Its dates apply to Anthropic-operated platforms; partner platforms set their own schedules. Requests to a retired model fail. Test the recommended replacement on your own workload before the retirement date. - [OpenAI API pricing](https://developers.openai.com/api/docs/pricing): Provider prices by model and processing mode, including cached input, built-in tools, audio and image generation. Public pricing documentation. No paid model call is made by this collection. A calculated estimate is not an invoice. Recheck the exact model, processing mode, region and effective date. - [OpenAI API deprecations](https://developers.openai.com/api/docs/deprecations): Announced retirements of OpenAI models and endpoints, with shutdown dates and recommended replacements. Public documentation. Notice periods differ by model type, and preview models can be retired with much shorter notice. A recommended replacement is the provider's suggestion, not a measured equivalent. Test it on your own task before the shutdown date. - [Gemini API pricing](https://ai.google.dev/gemini-api/docs/pricing): Free and paid tier prices for Gemini API models, including context caching, batch processing and search grounding. Public pricing documentation. An automated reader that does not keep cookies may be sent to a sign-in page instead. The page says free-tier content is used to improve Google products and paid-tier content is not. Confirm the tier and its data terms before sending private material. - [Gemini API deprecations](https://ai.google.dev/gemini-api/docs/deprecations): Gemini API models with release dates, shutdown dates and recommended replacements. Public documentation for the Gemini API. Check the schedule of any other Google platform you use separately. A replacement model can differ in price, limits and behavior. Measure it on the same test set before the shutdown date. - [OpenRouter models API](https://openrouter.ai/docs/api/api-reference/models/list-all-models-and-their-properties): An endpoint listing models available through OpenRouter with per-token prices, context length, supported parameters and modalities. Follow the documented authentication and request limits. A listing shows routing availability, not access through your own provider accounts. One model can be served by several providers at different prices and limits. Record the provider, price basis and retrieval date with any figure. - [Artificial Analysis methodology](https://artificialanalysis.ai/methodology): Definitions behind reported model quality, inference speed and price comparisons. Read the methodology and linked measurements; automated access or republication needs its own terms review. Keep the provider, endpoint, test configuration and measurement date with any cited result. ## Assess a model release Find model changes relevant to a task, then check access, licence and integration requirements. Decision question: Does a new model offer enough relevant benefit to justify an integration test? When to revisit: When a chosen publisher releases a model or changes access, licence, support or deployment requirements. Agent research task: Review the chosen publishers for relevant releases. Link the model card and exact revision, distinguish author claims from independent measurements, and identify a small compatibility test. Compare: - publisher and repository - exact revision or digest - release and observation dates - licence and gated access - supported task and deployment method Sources: - [Hugging Face Hub API](https://huggingface.co/docs/hub/api): Model, dataset and repository metadata for finding releases and inspecting model cards. Follow the documented endpoints, authentication and rate limits; gated repositories need authorized access. A repository listing is not a model licence. Inspect the model card, exact revision and permitted uses. - [Ollama model library](https://ollama.com/library): Model pages and available variants for an Ollama-compatible setup. Browse the published model pages. Availability in a library is not proof of access through a particular account. Check the model's own licence and variant. A listed size is not a complete working-memory estimate. ## Choose MCP tools and services Discover services an agent can connect to and inspect permissions before enabling them. Decision question: Which service supplies the required capability with acceptable permissions and maintenance? When to revisit: Before enabling a server, after a protocol or authentication change, and during periodic access reviews. Agent research task: Build a shortlist for the named task. Cite each server's official documentation, show required access and possible effects, and flag breaking changes without installing or connecting automatically. Compare: - publisher and server identity - protocol and server version - transport and authentication - requested scopes and effects - source licence and maintenance Sources: - [Official MCP Registry](https://modelcontextprotocol.io/registry/about): Server metadata and discovery documentation for MCP-compatible tools and services. Use the registry's documented read API and publisher references; discovery does not authorize a server connection. Registry inclusion does not certify safety, uptime or licence compatibility. Review each server and requested scope. - [GitHub Releases API](https://docs.github.com/en/rest/releases/releases): Release metadata for a chosen repository, including tags and published assets. Use the documented API with its authentication, pagination and request limits. Pin the repository and release identity. A release asset remains subject to its own licence and integrity checks. ## Turn papers into practical tests Find research that may improve a specific workflow and turn its claims into a reproducible test plan. Decision question: Which published method could improve this problem, and what would establish that it works here? When to revisit: During initial design, when a measured bottleneck appears, and when new evidence challenges the chosen method. Agent research task: Find papers for the supplied problem and explain the practical method in original words. Link the exact version, note conflicting evidence and outline a test before recommending an implementation. Compare: - paper identifier and version - publication versus update date - claimed method and baseline - code and data availability - licence and reproduction status Sources: - [arXiv API and feeds](https://info.arxiv.org/help/api/index.html): Research-paper metadata, version identifiers and links to public API and RSS documentation. Review the API terms, request limits and required attribution before collecting metadata. Paper licences vary. Preserve the paper version and distinguish an author's claim from an independently reproduced result. - [OpenAlex](https://help.openalex.org/): Research-work metadata and references for tracing papers, authors and related work. The help center documents API access, pricing and limits. Check the access conditions before a scheduled job. Metadata access does not grant rights to the linked full text. Do not treat citation counts as evidence of correctness. ## Pick a founder stack Compare a small operating stack against a startup's workload, budget and migration needs. Decision question: Which email, login, compute and storage choices fit the product and its operating budget? When to revisit: At initial design and during reviews of cost, reliability, customer requirements or migration needs. Agent research task: Compare two workable stacks for the supplied constraints. Assign one owner to login, email, compute and storage; cite current limits and explain what remains custom. Do not create accounts or spend money. Compare: - job and deployment constraints - current limits and billing units - identity and secret ownership - backup and export path - failure and migration procedure Sources: - [Cloudflare Workers](https://developers.cloudflare.com/workers/): Application hosting documentation for request handlers and related Cloudflare services. Public documentation; deploying an application requires an account and explicit resource authority. Check runtime limits, bindings, billing and migration constraints for the actual workload. - [Cloudflare R2](https://developers.cloudflare.com/r2/): Object-storage documentation for application files, datasets and media. Public documentation; bucket access and writes require scoped credentials. Storage does not establish content rights. Compare operations, retention, integrity checks and delivery controls. - [Fly.io](https://docs.fly.io/): Application and Machine documentation for workloads needing process and filesystem control. Public documentation; deployment and resource changes require account authority. Compare persistent storage, backups, regions, resource limits and operating costs for the chosen workload. - [Resend](https://resend.com/docs/introduction): Transactional email integration documentation for application messages. Sending requires a configured account, verified sender and an authorized message. A delivery integration is not consent to marketing. Check suppression, unsubscribe and provider requirements. - [Better Auth](https://better-auth.com/docs/introduction): Application authentication documentation covering a self-managed integration and supported features. Public documentation. Select and test the database adapter, account recovery and session settings. A library installation is not a secure migration. Test identity ownership, revocation and account linking. ## Plan platform and tool upgrades Find relevant releases, breaking changes and deprecations for a chosen technology stack. Decision question: Which announced changes require action in this stack, and which can wait? When to revisit: When a tracked dependency releases or deprecates a feature, and before a scheduled maintenance window. Agent research task: Review only the named dependencies and services. Separate a release announcement from a verified installation, and produce a change list with source links, applicability and a test or rollback step. Compare: - publisher and repository - version or announcement identity - published and effective dates - affected feature or dependency - migration and rollback steps Sources: - [GitHub Releases API](https://docs.github.com/en/rest/releases/releases): Release metadata for a chosen repository, including tags and published assets. Use the documented API with its authentication, pagination and request limits. Pin the repository and release identity. A release asset remains subject to its own licence and integrity checks. - [GitHub Changelog](https://github.blog/changelog/): Official product announcements and changes affecting GitHub users and integrations. Read the publisher's changelog; this collection does not republish its articles. Check rollout scope and deprecation dates in the original announcement before changing an integration. - [Cloudflare Changelog](https://developers.cloudflare.com/changelog/): Official changes across Cloudflare developer products. Read the product-specific entries and linked documentation. Distinguish announcement, account availability and measured behavior in your own deployment. ## Upgrade an agent framework Find breaking changes in agent frameworks, SDKs and the MCP specification before upgrading a working system. Decision question: Is this framework or SDK upgrade worth an integration test now, or can it wait? When to revisit: When a pinned framework, SDK or MCP revision publishes a release, and before you update dependencies. Agent research task: Compare the pinned version with the target release for each named package. Link the relevant release notes, separate stable releases from pre-releases, and list the integration tests to run before upgrading. Do not install or upgrade anything. Compare: - package, repository and pinned version - target release and publication date - breaking changes and deprecations - protocol revision supported - integration test result and rollback version Sources: - [MCP specification changelog](https://modelcontextprotocol.io/specification/latest/changelog): Changes in the current Model Context Protocol revision compared with the previous one, including breaking changes and deprecations. Public documentation. This address follows the latest revision; each revision also has its own dated page. The project is moving from the MIT licence to Apache-2.0; read its licence file before copying specification text. A published revision does not mean your SDK or host supports it yet. - [MCP Python SDK releases](https://github.com/modelcontextprotocol/python-sdk/releases): Tagged releases and change notes for the official MCP Python SDK. Read the release notes on GitHub, or use the GitHub Releases API with its request limits. MIT-licensed. Pin the version and run server and client tests before upgrading, especially across a major version. - [MCP TypeScript SDK releases](https://github.com/modelcontextprotocol/typescript-sdk/releases): Tagged releases and change notes for the official MCP TypeScript SDK. Read the release notes on GitHub, or use the GitHub Releases API with its request limits. The repository licence file describes a move from MIT to Apache-2.0. Pin the package version and run an integration test before upgrading. - [OpenAI Agents SDK releases](https://github.com/openai/openai-agents-python/releases): Tagged releases and change notes for OpenAI's Agents SDK for Python. Read the release notes on GitHub, or use the GitHub Releases API with its request limits. MIT-licensed. The project is still before version 1.0, so read each release note for breaking changes before upgrading. - [Claude Agent SDK for Python releases](https://github.com/anthropics/claude-agent-sdk-python/releases): Tagged releases and change notes for Anthropic's Claude Agent SDK for Python. Read the release notes on GitHub, or use the GitHub Releases API with its request limits. The SDK code is MIT-licensed; using Claude through it is governed by Anthropic's terms. Releases are frequent, so pin a version and test before upgrading. - [LangGraph releases](https://github.com/langchain-ai/langgraph/releases): Tagged releases for LangGraph and related packages, including its CLI, SDK and checkpoint libraries. Read the release notes on GitHub. One releases page covers several packages, so match the package name in each tag. MIT-licensed. Pin each package version separately and test saved checkpoints before upgrading. - [Pydantic AI releases](https://github.com/pydantic/pydantic-ai/releases): Tagged releases and change notes for the Pydantic AI agent framework. Read the release notes on GitHub. Pre-releases and fixes for an older major version appear beside current stable releases. MIT-licensed. Use a stable release for production and test structured outputs and tool calls before upgrading. - [GitHub Releases API](https://docs.github.com/en/rest/releases/releases): Release metadata for a chosen repository, including tags and published assets. Use the documented API with its authentication, pagination and request limits. Pin the repository and release identity. A release asset remains subject to its own licence and integrity checks. ## Standardize a coding agent version Choose which coding agent and version a team should run, and see what changed since the pinned one. Decision question: Which harness and version should the team standardize on, and what changed since the pinned one? When to revisit: When a harness the team uses publishes a stable release, and before changing the team's standard setup. Agent research task: Summarize changes between the team's pinned version and the newest stable release of each named harness. Flag changes to defaults, permission prompts, sandboxing and supported models, then propose a short trial on a real repository task before standardizing. Compare: - harness and pinned version - release channel and date - changed defaults, permissions and tools - supported models and providers - licence and data terms Sources: - [Claude Code changelog](https://code.claude.com/docs/en/changelog): Version-by-version changes to Claude Code, generated from the changelog in its public repository. Public documentation. The page is long; read only the entries between the pinned and target versions. Claude Code is proprietary. Its repository states that use is subject to Anthropic's Commercial Terms of Service. - [OpenAI Codex CLI releases](https://github.com/openai/codex/releases): Tagged releases of OpenAI's open-source Codex command-line coding agent. Read the release notes on GitHub. Alpha pre-releases appear beside stable releases. Apache-2.0 licensed. Using OpenAI models through it is governed by OpenAI's terms. - [OpenCode releases](https://github.com/anomalyco/opencode/releases): Tagged releases of the open-source OpenCode coding agent. Read the release notes on GitHub. Older links under the sst organization redirect to this repository. MIT-licensed. Model access is configured separately and governed by each provider's terms. - [Gemini CLI release notes](https://geminicli.com/docs/changelogs/): Release notes for Google's open-source Gemini CLI across its stable, preview and nightly channels. Public documentation on the site that the project's GitHub repository lists as its homepage. The project recommends the stable channel for general use. Apache-2.0 licensed. Using Gemini models through it is governed by Google's terms. - [Cursor changelog](https://cursor.com/changelog): Dated release notes for the Cursor editor and its agent features. Public page. This collection does not install, configure or sign in to the editor. Cursor is proprietary software. Check its terms and data settings before standardizing a team on a version. - [Aider release history](https://aider.chat/HISTORY.html): Release history of the open-source aider terminal coding assistant, including unreleased changes on its main branch. Public page. Check the date of the newest release before assuming active maintenance. Apache-2.0 licensed. Model access is configured separately and governed by each provider's terms. ## Check dependencies for advisories Find published vulnerabilities that affect the packages, tools and MCP servers an agent setup depends on. Decision question: Does a published advisory affect a dependency we run, and how soon must we act? When to revisit: Before a release, after adding a dependency or MCP server, and when an advisory source publishes a matching entry. Agent research task: Check the supplied dependency list against the advisory sources. Report exact matches with advisory links and fixed versions, mark uncertain matches, and propose the smallest safe update with a test. Do not change dependencies. Compare: - package, ecosystem and installed version - advisory identifier and aliases - affected and fixed version ranges - evidence of known exploitation - fix, mitigation and verification step Sources: - [OSV API](https://google.github.io/osv.dev/api/): Queries for known open-source vulnerabilities by package version, commit or advisory identifier, with a batch endpoint. Public API documentation. Its FAQ says the API currently has no rate limits; use batch queries for long dependency lists. OSV aggregates records from many source databases, each with its own licence listed on the OSV data page. Keep the advisory ID and fixed version with each finding. - [GitHub global security advisories API](https://docs.github.com/en/rest/security-advisories/global-advisories): Endpoints for listing and reading GitHub Advisory Database entries, filtered by ecosystem, affected package and advisory type. Use the documented API with its authentication and request limits. Malware advisories are excluded unless requested. GitHub publishes the advisory data under CC BY 4.0 in a public repository. Distinguish reviewed advisories from unreviewed ones in any report. - [CISA Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog): Vulnerabilities that CISA lists as known to be exploited, with dates added, remediation due dates, required actions and ransomware-use flags. Public catalog with CSV and JSON downloads and a JSON schema. Its due dates apply to US federal civilian agencies, not to other organizations. Absence from the catalog does not make a vulnerability safe to ignore. Match the exact product and version before acting on an entry. ## Choose a 3D or game engine Compare engines and 3D tools a creative agent can build on, using their own documentation and release notes. Decision question: Which engine or tool should a creative agent build this project on? When to revisit: At project start, before a major engine upgrade, and when a required platform or export format changes. Agent research task: Compare the named engines for the supplied project. Cite official documentation for scripting, export and platform support, note version-specific limits, and propose a small prototype that tests the riskiest requirement. Do not install or download anything. Compare: - project type and target platforms - engine version and release channel - scripting and automation interface - import, export and asset pipeline - licence for engine, scripts and assets Sources: - [Godot Engine documentation](https://docs.godotengine.org/en/stable/): The official manual and class reference for the Godot 2D and 3D game engine, including scripting and export guides. Public documentation. The stable and latest branches can differ; select the one that matches the engine version in use. The engine is MIT-licensed and the documentation is CC BY 3.0. Plugins, assets and templates keep their own licences. - [Godot download archive](https://godotengine.org/download/archive/): Every official Godot release, including development, pre-release and release-candidate builds, with links to release news and changelogs. Read the news and changelog for the exact build. This collection downloads nothing. Treat development and pre-release builds as test material. Back up a project before opening it in a newer engine version. - [Blender release notes](https://www.blender.org/download/releases/): Release notes for each Blender version, including long-term support releases, with links to detailed notes such as Python API changes. Public pages. The detailed notes and the Python API reference are on Blender's developer and documentation sites, which can show a browser check to automated readers. Blender is GPL software, and Blender states that published scripts using its Python API must use a GPL-compatible licence. - [Babylon.js documentation](https://doc.babylonjs.com/): Guides, API reference, what's new and breaking changes for the Babylon.js web rendering engine. Public documentation. Read the breaking changes page before moving a project to a new major version. The documentation states that its code samples are Apache 2.0 unless otherwise stated. Check the terms of models and textures separately. - [Babylon.js releases](https://github.com/BabylonJS/Babylon.js/releases): Tagged Babylon.js releases with change notes from the official repository. Read the release notes on GitHub, or use the GitHub Releases API with its request limits. Apache-2.0 licensed. Pin the package version and compare rendered output before upgrading a published scene. ## Connect creative tools through MCP Decide which MCP connection to a 3D tool is acceptable to enable, and under what isolation. Decision question: Which MCP connection to this creative tool is acceptable to enable, and with what isolation? When to revisit: Before enabling a server, after a server or protocol update, and before the project handles private files. Agent research task: Compare the named servers for the creative task. Show which tools can run code, write files or reach external services, and recommend an isolated setup such as a virtual machine. Do not install, connect or pre-approve tools. Compare: - publisher and official or community status - code execution and file access - external services and telemetry - maintenance activity and supported versions - isolation required before first use Sources: - [Blender Lab MCP Server](https://www.blender.org/lab/mcp-server/): Blender Lab's MCP server and add-on, which give an MCP client a natural-language interface to a Blender session through Blender's Python API. Requires Blender 5.1 or newer, the add-on, an MCP client and the server. Blender warns that it runs model-generated code without guards and recommends a virtual machine or a system without sensitive data. An official origin does not make generated code safe. Keep private files and credentials out of reach of the Blender session. - [MCP for Blender (community project)](https://github.com/ahujasid/mcp-for-blender): A widely used community MCP server and Blender add-on, not affiliated with the Blender Foundation. Its tools run arbitrary Python in Blender and fetch assets from external services. Third-party code that Baltor has not reviewed. Its README says a minimal anonymous usage record is sent by default and documents how to turn telemetry off. MIT-licensed code. Fetched assets keep their providers' terms, and several services need their own API keys or a paid plan. - [Godot MCP (community project)](https://github.com/Coding-Solo/godot-mcp): A widely used community MCP server for Godot, published outside the Godot project, that launches the editor, runs projects, captures debug output and edits scenes. Third-party code that Baltor has not reviewed. Its example client setup pre-approves tools that run projects and save scenes; review that list before use. MIT-licensed. Check recent repository activity and test against the Godot version in use before relying on it. - [MCP security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices): The protocol project's guidance on attacks and mitigations for MCP clients and servers, including local server compromise, token passthrough and server-side request forgery. Public documentation. This address follows the latest specification revision; earlier revisions have dated pages. Guidance is not an audit. Apply it to the exact server, transport and client configuration in use. - [Official MCP Registry](https://modelcontextprotocol.io/registry/about): Server metadata and discovery documentation for MCP-compatible tools and services. Use the registry's documented read API and publisher references; discovery does not authorize a server connection. Registry inclusion does not certify safety, uptime or licence compatibility. Review each server and requested scope. ## Track competitors and useful tools Find products that solve a named problem, then verify the claims at their own documentation. Decision question: Should we build, buy or reposition after comparing products that address this customer problem? When to revisit: During product positioning, before building a major feature, and when a relevant competitor changes its offering. Agent research task: Prepare a problem-based shortlist with primary product links and explicit unknowns. Do not equate launch popularity with usefulness or collect Product Hunt commercially without recorded permission. Compare: - problem and target user - publisher's product documentation - access and pricing date - integration and export options - measured versus advertised benefit Sources: - [Product Hunt API documentation](https://www.producthunt.com/v2/docs): Product discovery API documentation and access conditions. Commercial API use requires Product Hunt's permission. This is a reference link, not an enabled collection adapter. Do not automate commercial ingestion until permission is recorded. A launch rank is not a quality or demand measurement. - [GitHub Changelog](https://github.blog/changelog/): Official product announcements and changes affecting GitHub users and integrations. Read the publisher's changelog; this collection does not republish its articles. Check rollout scope and deprecation dates in the original announcement before changing an integration. ## Find a fitting hackathon Find events that match a project and check whether a reusable public demonstration is allowed. Decision question: Which event fits our project, eligibility and ability to publish the intended demonstration? When to revisit: Before committing project time, and again when event rules or submission deadlines change. Agent research task: Shortlist events for the stated skills, location and schedule. Verify each deadline and rule on the organizer's page; distinguish an eligible opportunity from a submitted application. Compare: - organizer and event URL - deadline and timezone - eligibility and team rules - data and code sharing rules - submission requirements Sources: - [Official Kaggle CLI](https://github.com/Kaggle/kaggle-cli): Official access tooling for competition, dataset and notebook discovery. Follow the account and authentication instructions. Competition participation may require accepting its rules. Check each competition's sharing rules and each dataset's licence before downloading, training or publishing a solution. - [Devpost hackathons](https://devpost.com/hackathons): Hackathon listings with organizer pages, eligibility and submission requirements. Browse organizer listings; no submission or account action is performed by this collection. Verify deadlines, geography, team eligibility and intellectual-property terms on the exact event page. ## Research market explanations Research public filings and economic releases that may explain a market event. Decision question: Which public events could explain the observed market activity, and which explanations remain unsupported? When to revisit: After a supplied market event or relevant filing or economic release, with event time and data vintage preserved. Agent research task: Build a dated source trail for the supplied event. Keep alternative explanations and missing market data visible. Do not infer trader identity, confirmed rolls or profitable signals from public context alone. Compare: - issuer or economic series - event and publication timestamps - filing amendment or data vintage - units and adjustment basis - observed fact versus explanation Sources: - [SEC EDGAR APIs](https://www.sec.gov/search-filings/edgar-application-programming-interfaces): Company submissions and structured filing data for source-based financial research. Follow SEC fair-access guidance and identify the client as required. This is not a live market-data feed. Retain filing accession, form, period and amendment status. A filing does not identify the intent behind an options trade. - [Federal Reserve Bank of St. Louis FRED API](https://fred.stlouisfed.org/docs/api/fred/): Economic series, releases and vintage information for macroeconomic context. The API requires its documented account credentials and terms. No credential is included here. Retain units, seasonal adjustment, observation date, release date and vintage. Some series have third-party restrictions. [Browse AgentFeeds](https://agentfeeds.si/feeds). Selecting a collection does not schedule a job or enable a service.