Skip to main content
Glama

DeltaSignal ATLAS-7

by net.aitrailblazer.api

DeltaSignal TripCode research packet

deltasignal_resolve_tripcode_research_packet
Read-onlyIdempotent

Use this read-only composite resolver as the default subscriber-facing TripCode tool. Parameters: tripcode is required and must be a public TF-SUB article TripCode. issuer, river_tripcode, limit, payload_mode, and include flags are optional. Behavior: read-only and idempotent with no destructive side effects; it resolves the current article object, discovers prior TF-SUB River nodes, runs the article thesis map, and returns one research_packet with article memory, River continuity, evidence refs, boundaries, missing evidence, and suggested follow-ups. It does not call Grok, does not mutate Azure Blob or Substack, does not invent missing evidence, and does not treat TripCodes as SEC identifiers or investment advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoOptional maximum prior article nodes to return. Defaults to 25.
issuerNoOptional issuer hint, such as HUT.
tickerNoOptional issuer hint alias.
tripcodeYesRequired TF-SUB article TripCode from a DeltaSignal article subtitle, for example TF-SUB-9DA70A7F98.
payload_modeNoOptional payload mode: compact or full. Compact is the default.
river_tripcodeNoOptional TF-RIVER root hint.
river_tripcodesNoOptional TF-RIVER root hints.
include_thesis_mapNoWhen true, include the thesis-map sections. The MVP defaults to running the thesis map.
include_unpublishedNoWhen true, include draft or unpublished article nodes when the caller is authorized.
include_article_bodyNoWhen true with available content, include article body fields. Compact mode returns metadata and hashes only.
include_prior_articlesNoWhen true, include discovered prior River nodes. The MVP defaults to including compact River nodes.
include_filing_evidenceNoWhen true, include filing evidence refs from the thesis map. The MVP keeps missing filing evidence explicit.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesOne TripCode-centered subscriber research packet across TF-SUB, TF-RIVER, TF-XBRL, and TF-DS continuity.
provenanceYesTraceability information for the MCP tool response.
mcp_summaryYesConcise high-signal summary of the tool response. Maximum 140 characters.
usage_metadataNoPerformance and estimated cost metadata for this MCP tool call.
suggested_follow_upsYesConcrete next MCP calls an agent can run to continue the workflow.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added
  2. Removed
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, but the description goes further by disclosing it does not call Grok, does not mutate Azure Blob or Substack, does not invent missing evidence, and is not investment advice. It also summarizes the internal resolution steps and return packet contents, adding significant context beyond 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 a single dense paragraph, but every sentence earns its place. It front-loads the main purpose and then packs in constraints and non-behaviors efficiently. It could be slightly improved with bullet formatting, but it is not wasteful.

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 (12 parameters, composite operation, output schema), the description covers the essential context: what it resolves, what it returns (article memory, River continuity, evidence refs, etc.), what it does not do, and the positioning as the default subscriber-facing tool. The output schema handles return details, and the description does not need to repeat them.

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%, so the baseline is 3. The description adds a bit of meaning by stating tripcode 'must be a public TF-SUB article TripCode' (schema only says 'required TF-SUB article TripCode') and listing optional parameter groups, but it does not elaborate on formats or interactions 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?

The description states a specific verb ('resolve') and resource ('research packet') and clearly positions this as the 'default subscriber-facing TripCode tool'. It also distinguishes from siblings like deltasignal_resolve_article_tripcode by calling itself a 'composite resolver', making its role unique.

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 'use this ... as the default subscriber-facing TripCode tool', giving clear context for when to pick it. However, it does not name alternatives or specify when not to use it, so it stops short of full exclusion guidance.

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

All DeltaSignal ATLAS-7 toolsInspect
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

B3.1/5.0
Disambiguation2/5

Significant overlap exists between atlas7_* and deltasignal_* tools for the same concepts (covenant stress, readiness, peer ranking, morning brief, pressure board), and composite workflows coexist with their low-level components. The descriptions are detailed but the sheer number of similar-scope tools makes misselection likely.

Naming Consistency4/5

Most tools follow a consistent lower_snake_case pattern with a domain prefix (atlas7_, deltasignal_, strategix_). Verb-first names (generate_, resolve_, search_) and noun-only names (alpha_opportunities, readiness) are both used, but the convention is predictable enough to navigate.

Tool Count1/5

With 81 tools, the surface is far beyond the 25–50 range considered excessive. Many tools are composites, natural-language variants, or near-duplicates that could be consolidated, creating an extreme mismatch for typical MCP server scope.

Completeness4/5

The tool surface is extensive, covering fundamentals, covenant stress, alpha screening, peer ranking, daily changes, briefs, historical ATLAS data, TripCode resolution, perp factors, synthetic ETF audit, and StrategiX rendering. Minor gaps exist (watchlist persistence, thesis lifecycle), but core research workflows are well covered.

Resources