sf)Referencia y espejo de problemas para @spfunctions/cli, la interfaz de línea de comandos compatible de SimpleFunctions para la infraestructura de mercados de predicción.
La CLI actual se distribuye a través de npm. Instale el paquete y trate el binario sf instalado como la fuente de verdad:
npm i -g @spfunctions/cli
sf login
sf status --json
sf world --json
sf describe --all --jsonsf es la superficie local principal para SimpleFunctions. Consulta el estado en tiempo real de Kalshi + Polymarket, inspecciona mercados y libros de órdenes, exporta JSON estructurado para agentes de codificación, ejecuta flujos de trabajo de tesis y portafolio, y mantiene los comandos de ejecución explícitos y con permisos restringidos.
Página de referencia pública para el paquete npm.
Rastreador de problemas para @spfunctions/cli.
Punto de instalación, soporte y descubrimiento para la superficie sf actual.
Related MCP server: MCP Predictive Market
No es el árbol de fuentes actual del tiempo de ejecución del operador completo.
No es el inventario de comandos canónico.
No debe utilizarse para inferir recuentos actuales de comandos, recuentos de mercado o comportamiento de ejecución.
Utilice sf describe --all --json para obtener el manifiesto de comandos instalado. Utilice https://simplefunctions.dev/api/internal/statistics para conocer los recuentos actuales de la superficie pública.
sf status --json
sf world --json
sf discover --quality --json
sf inspect <ticker> --jsonSi un comando no está disponible en su versión instalada, ejecute:
npm i -g @spfunctions/cli@latest
sf describe --all --jsonCLI: plano de control local principal para humanos, scripts de shell, cron, Claude Code, Codex y otros agentes de codificación.
API HTTP/Datos: superficie de red para servicios, paneles, cuadernos y trabajadores remotos.
SDK y tiempo de ejecución de agentes: envoltorios planificados sobre contratos de objetos estables de CLI/API.
MCP: adaptador de compatibilidad para hosts exclusivos de MCP, no el centro del producto canónico.
Página del producto CLI: https://simplefunctions.dev/cli
Paquete npm: https://www.npmjs.com/package/@spfunctions/cli
Documentación: https://docs.simplefunctions.dev
llms.txt: https://simplefunctions.dev/llms.txt
Catálogo de paquetes públicos: https://simplefunctions.dev/opensource
El espejo público tiene licencia MIT. La distribución npm compatible puede incluir código privado del tiempo de ejecución de SimpleFunctions.
Create a new thesis from a natural-language statement. The platform parses it, builds a causal tree, and schedules recurring evaluation. Side-effectful. Requires SF API key. Use fork_thesis instead if you want to start from an existing public thesis.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | SF API key (sf_live_...). Required. | |
| title | Yes | Thesis statement in natural language. Required. Example: "Brent crude closes above $90 by end of Q2 2026". | |
| metadata | No | Optional free-form metadata object (tags, source, notes). Stored verbatim. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It notes the tool is side-effectful, describes that it parses the statement, builds a causal tree, and schedules recurring evaluation. However, it lacks details on error handling, rate limits, or whether the action is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that cover purpose, behavior, requirements, and alternatives. Every sentence is informative and none are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description provides adequate context: purpose, alternative, side-effect, and API key requirement. It does not cover return values or error conditions, but for a creation tool with a clean schema, this is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 minimal value beyond the schema, only noting that the metadata is stored verbatim and giving a natural-language hint for the title. This does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new thesis from a natural-language statement, identifying the specific verb and resource. It also distinguishes itself from the sibling tool 'fork_thesis' by mentioning when to use that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus fork_thesis, and notes the requirement for an SF API key. It does not explicitly state when not to use it, but the alternative is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-reference arbitrary text against live prediction markets: paste an article or note, get back the markets relevant to its claims plus an LLM digest. POSTs content to the server; no auth required, no persistence. Use for one-off article enrichment; use monitor_the_situation for scheduled URL scraping with webhook delivery.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Raw text to analyze. Required. Max 50,000 characters. | |
| topics | Yes | Topic hints used to narrow the market search. Required, at least one. Free-form strings like "oil", "fed rates", "tsmc". | |
| model | No | LLM model id for the digest step. Default: gemini-2.5-flash. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool POSTs content (write operation), requires no auth, and does not persist data. This is good behavioral disclosure, though rate limits or error handling are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: core functionality, technical traits, usage guidance. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return (markets and LLM digest). It covers purpose, behavior, parameters, and usage guidance comprehensively for a tool with 3 simple params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds a note about the default model for the digest step but does not significantly enhance parameter understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cross-references arbitrary text against live prediction markets and returns relevant markets plus an LLM digest. It distinguishes itself from siblings by specifying one-off article enrichment vs. scheduled scraping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for one-off article enrichment; use monitor_the_situation for scheduled URL scraping with webhook delivery.' This provides clear when-to-use and when-not-to-use guidance with a specific alternative sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clone a public thesis (by id or slug) into the authenticated user's account, copying its causal tree as a starting point. Side-effectful. Requires SF API key. Use when you want to iterate on someone else's thesis; use create_thesis to start from scratch.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | SF API key (sf_live_...). Required. | |
| idOrSlug | Yes | Source thesis ID (uuid) or public slug. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Clearly labels as 'Side-effectful' and requires API key. Could add details like whether original is modified, but 'clone' implies no modification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words, front-loaded with main action. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple two-parameter tool with no output schema, description covers purpose, guidelines, and side-effects adequately. Could mention privacy of copied thesis but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description restates schema info but adds no extra semantics beyond what's already in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Clone a public thesis' with specific verb and resource, and distinguishes from sibling by referencing 'create_thesis' for starting from scratch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('iterate on someone else's thesis') and when not ('use create_thesis to start from scratch'), plus mentions API key requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What moved in the last 24 hours: incremental delta of probability changes across all tracked prediction markets, returned as compact markdown (~30-50 tokens). Read-only, no auth, no parameters. Thin wrapper over get_world_delta with since="24h"; use get_world_delta directly if you need a different lookback window or JSON output, or get_context for movers bundled with edges and highlights.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is read-only, requires no authentication, takes no parameters, and is a thin wrapper. No annotations exist, so description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. First sentence states purpose and output format, second sentence provides usage alternatives. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is complete: describes output (markdown, token count), behavior, and relationship to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters and 100% description coverage. Special case: baseline 4 for zero parameters. Description adds that there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves incremental delta of probability changes across all tracked prediction markets for the last 24 hours, returned as compact markdown. It distinguishes from siblings like get_world_delta and get_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (for 24h markdown) and when to use alternatives (get_world_delta for different lookback or JSON, get_context for bundled results). Provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE — single entry point that returns either a global market snapshot or a thesis-specific context bundle. Global mode (no args): top mispriced edges, 24h price movers, highlights, traditional markets. Thesis mode (thesisId + apiKey): adds causal tree, signal log, and evaluation history for that thesis. Read-only, no rate limit. Use this first; only call get_edges / get_changes / get_world_state if you need that single slice in isolation.
| Name | Required | Description | Default |
|---|---|---|---|
| thesisId | No | Thesis ID (uuid or slug). Omit for global snapshot. If set, apiKey is required. | |
| apiKey | No | SF API key (sf_live_...). Required when thesisId is set; ignored otherwise. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and no rate limit, beyond basic annotations (which are absent). Describes output content for both modes, providing 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, 4 sentences with zero waste. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with no output schema, description covers return content for both modes, usage order, and sibling tool differentiation. Fully sufficient for agent context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining the role of each parameter: omitting thesisId yields global snapshot, setting it requires apiKey. Clarifies conditional logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a single entry point returning either a global snapshot or thesis-specific bundle. Uses explicit 'START HERE' and differentiates modes, distinguishing from siblings like get_edges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this first; only call get_edges / get_changes / get_world_state if you need that single slice in isolation.' Provides clear guidance on when to use and when not to, with alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current mispricings (edges) detected across all public theses — contracts where the platform's causal model disagrees with market price. Read-only, no auth, no parameters. Returns only the edge list; use get_context for edges bundled with movers, highlights, and world state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description carries the burden well: states read-only, no authentication, no parameters, and explains what the tool returns. Lacks details like data freshness or rate limits, but for a simple data retrieval tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous words. Front-loaded with the key verb and resource, then adds context and differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value as 'the edge list' but does not detail the structure of each edge. Given no output schema, a brief field description would improve completeness, but the overall context is clear for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema, so no param descriptions are needed. The description correctly reinforces that there are no parameters. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes what the tool does: returns current mispricings (edges) across all public theses. Clearly distinguishes from sibling 'get_context' by stating it returns only the edge list, while get_context bundles edges with other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for a pure edge list. Provides alternative: use get_context for edges bundled with movers, highlights, and world state. Also notes read-only, no auth, no parameters, giving clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List live prediction market contracts with current YES/NO prices, 24h volume, and metadata. Read-only, no auth. Use for deep dives on a specific topic; use search_markets if you have a keyword instead of a topic, or get_context for a high-level overview.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic filter. Allowed values: energy, rates, fx, equities, crypto, volatility. Omit for all topics. | |
| limit | No | Max contracts to return. Default 50. Hard cap 500. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It explicitly states 'Read-only, no auth', which is sufficient for a simple listing tool. However, it omits details like rate limits or response format, which would add safety margin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste: purpose, read-only claim, and usage guidance in a logical order. Every sentence adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool returns (prices, volume, metadata) and when to use alternatives. With only 2 parameters and no output schema, the description provides adequate context. It could mention pagination but is still sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description does not add any parameter detail beyond what is already in the schema. It does not explain syntax, constraints, or examples, so it neither helps nor harms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb ('List') and specifies the resource ('live prediction market contracts') and included data ('YES/NO prices, 24h volume, metadata'). It explicitly differentiates from siblings by naming search_markets and get_context, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use for deep dives on a specific topic', and names two alternatives (search_markets with keyword, get_context for overview). This clearly sets usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-generated trade ideas derived from active theses and current market data, each with rationale and target contract. Read-only, no auth, no parameters. Use when you want pre-packaged actionable suggestions; use get_edges for raw mispricings without commentary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, no authentication required, and no parameters. Since annotations are absent, the description adequately covers key behavioral traits for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. First sentence states purpose and output; second sentence provides usage guidance and distinguishes from sibling. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is fully complete. It covers what the tool does, its operational characteristics (read-only, no auth), and how to choose between it and a sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so baseline is 4. Description does not need to add parameter information beyond the input schema, which is fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states tool returns 'AI-generated trade ideas derived from active theses and current market data, each with rationale and target contract.' It distinguishes itself from sibling 'get_edges' by noting the difference in output (pre-packaged suggestions vs raw mispricings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool ('when you want pre-packaged actionable suggestions') and when to use the alternative ('use get_edges for raw mispricings without commentary'). Also states it is read-only and requires no auth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Incremental diff of the world model since a given timestamp — only the markets whose probability moved. ~30-50 tokens vs ~800 for the full state from get_world_state. Read-only, no auth. Use this for cheap polling loops; use get_world_state for an absolute snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | Lookback window. Either a relative duration (30m, 1h, 6h, 24h) or an ISO-8601 timestamp. Required. | |
| format | No | Output format. Default: markdown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: read-only, no authentication required, and token size estimate (~30-50 tokens vs ~800). With no annotations, the description fully handles transparency for this simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The key concept is front-loaded, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers purpose, usage, behavioral specifics, and sibling comparison. No gaps for an agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The tool description adds no extra parameter-specific meaning beyond what the schema already provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an incremental diff of the world model, specifying it returns only markets with probability movement. It explicitly contrasts with sibling get_world_state, distinguishing cheap polling from absolute snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this for cheap polling loops; use get_world_state for an absolute snapshot.' Clearly states when to use this tool and when to use the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calibrated world model: ~9,700 live prediction markets distilled into ~800 tokens of real-money probabilities across geopolitics, economics, tech, and policy. Read-only, no auth, no rate limit. Use when you need a compact snapshot of "what the market believes right now"; use get_changes for deltas only, or get_context for the broader bundle including edges and movers.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | Comma-separated topic filter. Allowed values: energy, geo, tech, policy, crypto, finance. Omit for all topics. | |
| format | No | Output format. Default: markdown (human-readable). Use json for programmatic parsing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully takes on behavioral disclosure. It states 'Read-only, no auth, no rate limit,' clearly indicating safe, unrestricted usage. It also explains the core behavior of distilling markets into tokens. While it doesn't detail return format or size limits, the information is sufficient for a read-only tool of this nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long. The first sentence concisely sets context and capabilities. The second provides usage guidance and alternatives. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, no output schema), the description covers all essential aspects: what it does, its source data, security profile, and relation to siblings. It is fully complete for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra detail beyond what the schema already provides for the parameters (focus and format). It does not reiterate or elaborate on parameter usage, so it adds no additional value to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a compact snapshot of market beliefs from live prediction markets, specifying the sources (~9,700 markets), coverage (geopolitics, economics, tech, policy), and output nature (real-money probabilities). It distinguishes itself from siblings by naming get_changes and get_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('when you need a compact snapshot of what the market believes right now') and provides clear alternatives for other needs ('use get_changes for deltas only, or get_context for the broader bundle'). This is excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append an external observation (news headline, user note, data point) to a thesis. Stored in the thesis signal log and consumed on the next evaluation cycle — does NOT trigger evaluation by itself; call trigger_evaluation afterward if you need an immediate update. Writes state. Requires SF API key.
| Name | Required | Description | Default |
|---|---|---|---|
| thesisId | Yes | Target thesis ID. Required. Get one from list_theses. | |
| apiKey | Yes | SF API key (sf_live_...). Required. | |
| content | Yes | Signal text. Required, non-empty. Free-form natural language. | |
| type | No | Signal classification. Default: external. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool writes state and stores data in the thesis signal log, consumed on the next evaluation cycle. However, it does not detail other potential side effects, concurrency behavior, or error conditions. With no annotations provided, the description carries the full burden, but it only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the primary action. Every sentence provides essential information without redundancy. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers purpose, usage, prerequisites, and behavior. Missing details on return value (no output schema) and error handling, but given the tool's simplicity and the presence of sibling guidance, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters thoroughly (100% coverage). The description adds a brief classification of the content field as 'external observation (news headline, user note, data point)' and mentions the default type, but this is minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool appends external observations like news headlines, user notes, or data points to a thesis. It distinguishes itself from the sibling trigger_evaluation by explicitly noting that this tool does not trigger evaluation, thus clarifying its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 and when to use a sibling tool, stating 'does NOT trigger evaluation by itself; call trigger_evaluation afterward if you need an immediate update.' Also mentions a prerequisite: 'Requires SF API key.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every thesis owned by the authenticated user, with id, title, status, and last evaluation timestamp. Read-only. Requires SF API key. Use to discover thesisId values needed by get_context, trigger_evaluation, inject_signal, and fork_thesis.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | SF API key (sf_live_...). Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It declares the tool is read-only and requires the SF API key, which covers the main behavioral traits. For a simple list operation with one parameter, this is adequate; no further behavioral details like pagination are needed given the 'list every thesis' phrasing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sentence states the purpose and return fields, second sentence provides usage guidance linking to other tools. Every sentence is necessary and front-loaded. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description explains the fields returned, that it returns all theses for the authenticated user, and why to use it (to get thesisId). This is complete for its complexity level; no additional details are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a full description for the apiKey parameter, including the required format (sf_live_...). The tool description merely repeats 'Requires SF API key' without adding new semantic meaning. With 100% schema coverage, the baseline is 3, and no additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', specifies the resource 'theses owned by the authenticated user', and lists the fields returned (id, title, status, last evaluation timestamp). It distinguishes itself from siblings by mentioning it is used to discover thesisId values needed by other tools like get_context, trigger_evaluation, inject_signal, and fork_thesis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: to discover thesisId values for other tools. It also notes it is read-only and requires an API key. However, it does not explicitly state when not to use it or provide alternatives, though the sibling list makes it clear this is the only list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End-to-end pipeline: scrape one or more URLs (or run a search/crawl/map/extract), optionally analyze with an LLM against a prompt + JSON schema, optionally cross-reference with prediction markets, and return the bundle. Side-effectful (calls Firecrawl + LLM, billed). Requires SF API key. Use for scheduled or one-shot URL ingestion; use enrich_content if you already have the text in hand.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | SF API key (sf_live_...). Required. | |
| source | Yes | Source configuration. Exactly one of url/urls/query must be set, matching the chosen action. | |
| analysis | No | LLM analysis step. Omit to skip. | |
| enrich | No | Market enrichment step. Omit to skip. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries burden. It discloses side effects (calls Firecrawl + LLM, billed) and auth requirements (SF API key). However, it does not detail the return bundle structure or potential error states, leaving some behavioral aspects implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, well-structured paragraph. First sentence defines purpose, second covers side effects and requirements, third gives usage guidance. No redundancy, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (multi-step, optional components), description is fairly complete: covers actions, optional steps, trade-offs. Return format is not described (no output schema), but context signals indicate no output schema, so burden is on description. Description could be more explicit about the bundle contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds context by naming the optional analysis and enrichment steps but does not provide significant new meaning beyond what the schema offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly defines the tool as an end-to-end pipeline for scraping URLs (or search/crawl/map/extract) with optional LLM analysis and prediction market enrichment. It distinguishes itself from the sibling 'enrich_content' by specifying that this tool is for URL ingestion, not for already available text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use for scheduled or one-shot URL ingestion' and when not: 'use enrich_content if you already have the text in hand.' Also notes side effects and billing, providing clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch real-time and historical market data from Databento (CME futures, US equities, crypto). Read-only, billed per Databento usage. Use for OHLCV / trades / quotes on traditional instruments; use get_markets or search_markets for prediction-market contracts instead.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | Symbol list. Required, at least one. Examples: ["CL.c.0"] (front-month WTI), ["ES.c.0"] (S&P e-mini), ["AAPL"]. Continuous-contract suffix .c.0 means front month. | |
| dataset | No | Databento dataset code. Default: GLBX.MDP3 (CME Globex). Must match the venue of the requested symbols. | |
| schema | No | Databento schema. Default: trades. Other common values: ohlcv-1m, ohlcv-1d, mbp-1, tbbo, statistics. | |
| start | No | ISO-8601 start timestamp (inclusive). Omit for most recent data. | |
| end | No | ISO-8601 end timestamp (exclusive). Must be after start if both set. | |
| limit | No | Max records returned. Default 100. Hard cap 10000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and billing per usage. No annotations exist, so description carries full burden. Could mention data ordering or error handling but still provides key 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two highly informative sentences with no filler. Front-loaded purpose, followed by usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameters, and billing. No output schema, so return format is omitted, but for a data-fetching tool with good parameter descriptions, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds extra context: continuous-contract suffix explanation, dataset default, and symbol examples, improving parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches real-time and historical market data from Databento, specifying the resource and verb. It distinguishes from siblings by directing prediction-market queries to get_markets or search_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (for traditional instruments OHLCV/trades/quotes) and when to use alternatives (prediction markets), with clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search prediction market contracts by keyword across question text and resolution criteria. Read-only, no auth. Use when you have a free-form term ("OPEC", "Powell", "TSMC"); use get_markets if you only want to filter by predefined topic.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keyword or phrase. Required, non-empty. Matches question text and resolution criteria. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explicitly states 'Read-only, no auth', which discloses important behavioral traits. It could mention pagination or result limits, but for a simple search, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, front-loaded with the core purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers purpose, usage guidelines, and behavioral transparency completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a descriptive parameter comment. The tool description essentially restates the schema's parameter info ('matches question text and resolution criteria'), adding no new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource 'prediction market contracts', and specifies the scope 'by keyword across question text and resolution criteria'. It effectively distinguishes from sibling tool 'get_markets' which filters by predefined topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Use when you have a free-form term' and explicitly contrasts with 'get_markets' for predefined topic filtering, providing clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force an immediate thesis evaluation: consumes pending signals, re-scans edges, and updates confidence scores. Side-effectful and LLM-billed (typically 5-30s, may be rate-limited per plan). Requires SF API key. Use after inject_signal when you need fresh output now; otherwise theses re-evaluate on their own schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| thesisId | Yes | Target thesis ID. Required. Get one from list_theses. | |
| apiKey | Yes | SF API key (sf_live_...). Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses side-effectfulness, LLM billing, typical latency (5-30s), rate limits, and requirement for SF API key. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with purpose and effect, followed by usage context and when-to-use. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains what happens (updates confidence scores) but lacks detail on return value. Still sufficient for a trigger action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add meaning beyond schema's parameter descriptions: thesisId and apiKey are required, apiKey format hinted elsewhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forces an immediate thesis evaluation, consuming pending signals, re-scanning edges, and updating confidence scores. This distinguishes it from sibling tools like inject_signal (which injects signals) and list_theses (which lists theses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use after inject_signal when fresh output is needed immediately; otherwise, theses re-evaluate automatically. This provides clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.2create_thesis4 fields changedInput schema / properties / apiKey / descriptionAdded value: +"SF API key (sf_live_...). Required."Input schema / properties / metadata / descriptionAdded value: +"Optional free-form metadata object (tags, source, notes). Stored verbatim."Input schema / properties / title / descriptionPrevious value: -"Thesis statement"New value: +"Thesis statement in natural language. Required. Example: \"Brent crude closes above $90 by end of Q2 2026\"."Input schema / properties / title / minLengthAdded value: +1enrich_content6 fields changedInput schema / properties / content / descriptionPrevious value: -"Text content to analyze (max 50,000 chars)"New value: +"Raw text to analyze. Required. Max 50,000 characters."Input schema / properties / content / maxLengthAdded value: +50000Input schema / properties / content / minLengthAdded value: +1Input schema / properties / model / descriptionPrevious value: -"LLM model for digest (default: gemini-2.5-flash)"New value: +"LLM model id for the digest step. Default: gemini-2.5-flash."Input schema / properties / topics / descriptionPrevious value: -"Topics to search for in prediction markets"New value: +"Topic hints used to narrow the market search. Required, at least one. Free-form strings like \"oil\", \"fed rates\", \"tsmc\"."Input schema / properties / topics / minItemsAdded value: +1fork_thesis3 fields changedInput schema / properties / apiKey / descriptionAdded value: +"SF API key (sf_live_...). Required."Input schema / properties / idOrSlug / descriptionPrevious value: -"Thesis ID or public slug"New value: +"Source thesis ID (uuid) or public slug. Required."Input schema / properties / idOrSlug / minLengthAdded value: +1get_context2 fields changedInput schema / properties / apiKey / descriptionPrevious value: -"SF API key. Required for thesis-specific context."New value: +"SF API key (sf_live_...). Required when thesisId is set; ignored otherwise."Input schema / properties / thesisId / descriptionPrevious value: -"Thesis ID. Omit for global market snapshot."New value: +"Thesis ID (uuid or slug). Omit for global snapshot. If set, apiKey is required."get_markets5 fields changedInput schema / properties / limit / descriptionAdded value: +"Max contracts to return. Default 50. Hard cap 500."Input schema / properties / limit / exclusiveMinimumAdded value: +0Input schema / properties / limit / maximumAdded value: +9007199254740991Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / topic / descriptionPrevious value: -"Filter: energy, rates, fx, equities, crypto, volatility"New value: +"Topic filter. Allowed values: energy, rates, fx, equities, crypto, volatility. Omit for all topics."get_world_delta2 fields changedInput schema / properties / format / descriptionAdded value: +"Output format. Default: markdown."Input schema / properties / since / descriptionPrevious value: -"Relative (30m, 1h, 6h, 24h) or ISO timestamp"New value: +"Lookback window. Either a relative duration (30m, 1h, 6h, 24h) or an ISO-8601 timestamp. Required."get_world_state2 fields changedInput schema / properties / focus / descriptionPrevious value: -"Comma-separated topics: energy,geo,tech,policy,crypto,finance"New value: +"Comma-separated topic filter. Allowed values: energy, geo, tech, policy, crypto, finance. Omit for all topics."Input schema / properties / format / descriptionAdded value: +"Output format. Default: markdown (human-readable). Use json for programmatic parsing."inject_signal5 fields changedInput schema / properties / apiKey / descriptionAdded value: +"SF API key (sf_live_...). Required."Input schema / properties / content / descriptionPrevious value: -"Signal content"New value: +"Signal text. Required, non-empty. Free-form natural language."Input schema / properties / content / minLengthAdded value: +1Input schema / properties / thesisId / descriptionAdded value: +"Target thesis ID. Required. Get one from list_theses."Input schema / properties / type / descriptionAdded value: +"Signal classification. Default: external."list_theses1 field changedInput schema / properties / apiKey / descriptionPrevious value: -"SF API key"New value: +"SF API key (sf_live_...). Required."monitor_the_situation15 fields changedInput schema / properties / analysis / descriptionAdded value: +"LLM analysis step. Omit to skip."Input schema / properties / analysis / properties / enabled / descriptionAdded value: +"Set true to run LLM analysis on scraped content."Input schema / properties / analysis / properties / model / descriptionAdded value: +"LLM model id. Default: gemini-2.5-flash."Input schema / properties / analysis / properties / prompt / descriptionAdded value: +"LLM prompt. Required when enabled."Input schema / properties / analysis / properties / schema / descriptionAdded value: +"Optional JSON schema for structured output."Input schema / properties / apiKey / descriptionAdded value: +"SF API key (sf_live_...). Required."Input schema / properties / enrich / descriptionAdded value: +"Market enrichment step. Omit to skip."Input schema / properties / enrich / properties / enabled / descriptionAdded value: +"Set true to cross-reference scraped content with prediction markets."Input schema / properties / enrich / properties / topics / descriptionAdded value: +"Topic hints for the market search. Required when enabled."Input schema / properties / source / descriptionAdded value: +"Source configuration. Exactly one of url/urls/query must be set, matching the chosen action."Input schema / properties / source / properties / action / descriptionAdded value: +"Firecrawl action. Required. \"scrape\"=single url, \"batch_scrape\"=multiple urls, \"crawl\"=follow links, \"search\"=web search by query, \"map\"=site map, \"extract\"=structured extraction."Input schema / properties / source / properties / options / descriptionAdded value: +"Pass-through options forwarded to Firecrawl."Input schema / properties / source / properties / query / descriptionAdded value: +"Search query. Required for action=search."Input schema / properties / source / properties / url / descriptionAdded value: +"Single URL. Required for action=scrape/crawl/map/extract."Input schema / properties / source / properties / urls / descriptionAdded value: +"URL list. Required for action=batch_scrape."query_databento10 fields changedInput schema / properties / dataset / descriptionPrevious value: -"Databento dataset (default: GLBX.MDP3)"New value: +"Databento dataset code. Default: GLBX.MDP3 (CME Globex). Must match the venue of the requested symbols."Input schema / properties / end / descriptionPrevious value: -"ISO date"New value: +"ISO-8601 end timestamp (exclusive). Must be after start if both set."Input schema / properties / limit / descriptionPrevious value: -"Max results (default: 100)"New value: +"Max records returned. Default 100. Hard cap 10000."Input schema / properties / limit / exclusiveMinimumAdded value: +0Input schema / properties / limit / maximumAdded value: +9007199254740991Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / schema / descriptionPrevious value: -"Data schema (default: trades)"New value: +"Databento schema. Default: trades. Other common values: ohlcv-1m, ohlcv-1d, mbp-1, tbbo, statistics."Input schema / properties / start / descriptionPrevious value: -"ISO date"New value: +"ISO-8601 start timestamp (inclusive). Omit for most recent data."Input schema / properties / symbols / descriptionPrevious value: -"Symbols like CL.c.0, ES.c.0, AAPL"New value: +"Symbol list. Required, at least one. Examples: [\"CL.c.0\"] (front-month WTI), [\"ES.c.0\"] (S&P e-mini), [\"AAPL\"]. Continuous-contract suffix .c.0 means front month."Input schema / properties / symbols / minItemsAdded value: +1search_marketstrigger_evaluation2 fields changedInput schema / properties / apiKey / descriptionAdded value: +"SF API key (sf_live_...). Required."Input schema / properties / thesisId / descriptionAdded value: +"Target thesis ID. Required. Get one from list_theses."v0.1.0get_marketsget_world_deltainject_signalmonitor_the_situationsearch_marketsv0.1.1create_thesisenrich_contentfork_thesisget_changesget_contextget_edgesget_trade_ideasget_world_statelist_thesesquery_databentosearch_marketstrigger_evaluationTools are mostly distinct with clear descriptions, but the large number of 'get_*' tools (get_changes, get_context, get_edges, get_markets, get_trade_ideas, get_world_delta, get_world_state) could confuse an agent if not carefully read. However, each serves a unique purpose.
All tool names follow a consistent verb_noun snake_case pattern (e.g., create_thesis, enrich_content, get_markets). No mixing of conventions, making the naming predictable and clear.
16 tools is slightly above the ideal range but still reasonable for the server's scope (thesis management, market data, enrichment). Each tool has a distinct role, and the count does not feel excessive.
The tool surface covers core thesis creation, listing, and evaluation, but lacks update and delete operations for theses. Additionally, there is no direct trade execution tool, which may be intentional. Notable gaps in lifecycle management.
Live Kalshi and Polymarket data: EV edges, cross-venue arbitrage, markets, and whale trades.
Prediction-market intelligence for conservative cross-market pricing edges and live signals.
Live Kalshi + Polymarket prediction-market data and cross-venue arbitrage spreads, one schema.
Polymarket & Kalshi whale trades, ranked traders, backtesting and Autopilot. $15/mo.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/spfunctions/simplefunctions-cli'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
