Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@JACTUS MCP Server Simulate a $100,000 PAM loan at 5% interest maturing in 1 year"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Standalone MCP server for JACTUS — Enables AI assistants like Claude Code to directly access JACTUS financial contract simulation capabilities.
Model Context Protocol (MCP) is a protocol that allows AI assistants to interact with external tools. This package gives Claude (and other MCP-compatible assistants) the ability to discover, validate, and simulate all 18 ACTUS financial contract types powered by JACTUS.
Related MCP server: SSCMFI Bond Analytics MCP Server
pip install jactus-mcpThis installs the MCP server and pulls jactus as a dependency automatically.
After installing, optionally download JACTUS documentation and examples from GitHub:
jactus-mcp setupThis downloads the matching version's docs/ and examples/ into ~/.jactus-mcp/data/. You can also specify a tag:
jactus-mcp setup --tag v0.2.0 # specific version
jactus-mcp setup --force # re-download
jactus-mcp status # check what's downloaded
jactus-mcp clean # remove downloaded datapip install git+https://github.com/pedronahum/JACTUS-MCP.gitgit clone https://github.com/pedronahum/JACTUS-MCP.git
cd JACTUS-MCP
pip install -e ".[dev]"Add to your Claude Code MCP settings (.mcp.json or settings):
{
"mcpServers": {
"jactus": {
"command": "jactus-mcp"
}
}
}Or using Python module:
{
"mcpServers": {
"jactus": {
"command": "python",
"args": ["-m", "jactus_mcp"]
}
}
}Add to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"jactus": {
"command": "jactus-mcp"
}
}
}# Default: stdio transport (for local clients)
jactus-mcp
# or
python -m jactus_mcp
# Streamable HTTP transport (for remote clients)
python -m jactus_mcp --transport streamable-httpThese tools work with just pip install jactus-mcp — no source tree needed:
Tool | Description |
| List all 18 contract types by category |
| Get detailed info about a contract type |
| Get required/optional parameters for all 18 types |
| List all ACTUS event types |
| List all risk factor observer types |
| Simulate a contract and get structured cash flows |
| Validate contract attributes before simulation |
| Compute DV01, delta, gamma, PV01 risk metrics |
| Simulate a portfolio with aggregation |
| Structured guides on 7 topics |
| Built-in PAM quick start example |
| Verify installation and JACTUS availability |
| Version information |
These tools require JACTUS docs/examples. Enable them with jactus-mcp setup:
Tool | Description |
| Search across JACTUS documentation |
| Browse documentation files and headers |
| List Python scripts and notebooks |
| Retrieve example source code |
| Execute an example |
Alternatively, point to a local JACTUS checkout:
export JACTUS_ROOT=/path/to/JACTUSResource URI | Description |
| System architecture guide |
| PAM contract walkthrough |
| Derivative contracts guide |
| Project overview |
| Dynamic contract info + schema |
Prompt | Description |
| Guide to create a new contract |
| Help troubleshoot errors |
| Explain a contract type |
| Compare two contract types |
With the MCP server running, ask Claude:
"Simulate a $100k PAM loan at 5% interest maturing in 1 year"
Claude will:
Call jactus_get_contract_schema("PAM") to get required fields
Call jactus_simulate_contract with the attributes
Return structured cash flow events (IED, IP, MD) with payoff amounts
JACTUS implements all 18 ACTUS contract types:
Principal: PAM, LAM, LAX, NAM, ANN, CLM
Non-Principal: UMP, CSH, STK
Exotic: COM
Derivatives: FXOUT, OPTNS, FUTUR, SWPPV, SWAPS, CAPFL, CEG, CEC
# Unit tests
pytest tests/ -v --ignore=tests/test_mcp_integration.py
# Integration tests (requires MCP stdio client)
pytest tests/test_mcp_integration.py -v
# All tests
pytest tests/ -vJACTUS-MCP/
├── src/jactus_mcp/
│ ├── __init__.py # Package version
│ ├── __main__.py # python -m jactus_mcp entry point
│ ├── server.py # FastMCP server (tools, resources, prompts)
│ ├── models.py # Pydantic response models
│ └── tools/
│ ├── _utils.py # Shared utilities (get_jactus_root, type conversion)
│ ├── contracts.py # Contract discovery & schema (18 types)
│ ├── simulate.py # Contract simulation
│ ├── examples.py # Example retrieval & execution
│ ├── validation.py # Attribute validation
│ ├── documentation.py # Documentation search & topic guides
│ ├── risk.py # Risk analytics (DV01, delta, gamma)
│ └── system.py # Health checks & version info
├── tests/ # Comprehensive test suite
├── pyproject.toml # Package configuration
└── README.mdApache License 2.0
Compute risk metrics (DV01, delta, gamma, PV01) for a contract.
Uses finite difference approximation on the nominal interest rate. Returns the metric value, base PV, and computation parameters.
Args: attributes: Contract attributes dict (same format as simulate). risk_metric: One of "dv01", "delta", "gamma", "pv01". base_rate: Base nominal interest rate (default 0.05). bump_size: Finite difference bump size (default 0.0001 = 1bp).
| Name | Required | Description | Default |
|---|---|---|---|
| base_rate | No | ||
| bump_size | No | ||
| attributes | Yes | ||
| risk_metric | No | dv01 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the computational method (finite difference approximation on nominal interest rate) and the return value structure. No annotations exist, so the description carries full burden. It does not explicitly state it is read-only or idempotent, but the method description provides good insight.
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?
Structured with summary, method note, returns line, and parameter list. The Args block is necessary given empty schema descriptions. Could be slightly more concise by merging the method note with the summary, but overall 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?
Covers method, all parameters, and return values. References 'same format as simulate' for attributes, leveraging existing knowledge. Output schema exists so return details are less critical. Lacks explicit example usage or note about performance/accuracy, but adequate.
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 schema has 0% description coverage, so the description fully compensates with an 'Args' block explaining each parameter: attributes (format same as simulate), risk_metric (enumeration of values), base_rate (default 0.05), bump_size (default 1bp). This adds significant meaning 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 it computes specific risk metrics (DV01, delta, gamma, PV01) for a contract, distinguishing it from sibling tools like simulate_contract which likely compute prices. The verb 'compute' is specific and the resource is 'risk metrics for a contract'.
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?
No guidance on when to use this tool versus alternatives such as simulate_contract or simulate_portfolio. The description does not mention exclusions or contexts where another tool is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific ACTUS contract type.
Returns the contract description, category, implementation class, MCP simulatability status, and whether a ChildContractObserver is required. Use this to understand what a contract type represents and whether it can be simulated via MCP.
Args: contract_type: ACTUS contract type code. Examples: PAM (bonds/loans), LAM (amortizing loans), ANN (mortgages), SWPPV (interest rate swaps), OPTNS (options), FXOUT (FX forwards).
| Name | Required | Description | Default |
|---|---|---|---|
| contract_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what is returned (description, category, implementation class, simulatability, observer requirement). However, it omits any side effects, authentication needs, rate limits, or error conditions. For a read operation, this is adequate but not exhaustive.
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 concise, with a clear first sentence stating purpose, a brief list of returned information, a usage hint, and an Args section. It is well-structured but could be slightly more streamlined by integrating the Args into the prose.
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 and the presence of an output schema, the description covers the essential aspects: what the tool does, what it returns, and how to use it. There are no major gaps for an informational retrieval 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?
The input schema has 0% description coverage, so the description adds significant value. It explains the parameter 'contract_type' is an ACTUS code and provides concrete examples (PAM, LAM, ANN, etc.), which helps an agent understand valid values 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?
The description explicitly states 'Get detailed information about a specific ACTUS contract type.' It then lists the returned fields and distinguishes itself from siblings like jactus_list_contracts by focusing on a single type.
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 says 'Use this to understand what a contract type represents and whether it can be simulated via MCP,' providing clear context. It does not explicitly mention when not to use or list alternatives, but the sibling tools and the phrase 'specific contract type' imply its scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get required and optional parameters for a contract type.
Returns field names, types, descriptions, and example Python code — everything needed to build valid attributes for jactus_simulate_contract. This is the authoritative source for contract parameters; there is no need to read source code.
Also indicates whether the contract can be simulated via MCP or requires the Python API (e.g., contracts needing a ChildContractObserver).
Args: contract_type: ACTUS contract type code (e.g., PAM, LAM, SWPPV).
| Name | Required | Description | Default |
|---|---|---|---|
| contract_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return contents (field names, types, descriptions, example code) and additional behavior (indicates simulation feasibility). With no annotations, the description carries full burden; it is thorough but could explicitly state it is read-only and has no side effects.
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?
Concise and front-loaded: first sentence states core purpose, followed by detailed return list, authority claim, and additional behavior. Parameter documentation is explicit and efficient. No unnecessary 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 the complexity of the tool (schema retrieval) and presence of an output schema, the description provides complete context: purpose, return details, authority, simulation indicator, and parameter meaning. No gaps identified.
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?
Adds significant meaning beyond the input schema: specifies the parameter is an ACTUS contract type code and provides examples (PAM, LAM, SWPPV). Since schema description coverage is 0%, the description fully compensates and provides necessary context.
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 'Get required and optional parameters for a contract type' and elaborates on returns and purpose. Differentiates from siblings by positioning itself as the authoritative source for contract parameters and linking to jactus_simulate_contract.
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 directs users to this tool as the authoritative source, advises against reading source code, and mentions it indicates simulation capability. Implicitly guides use before jactus_simulate_contract, but lacks explicit comparison to sibling tools like jactus_get_contract_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the structure of JACTUS documentation, listing all files with their section headers.
Returns available documentation files with their headers, useful for understanding what documentation is available before searching.
Note: Requires JACTUS source tree access. Set JACTUS_ROOT env var if needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that the tool returns file names with headers and requires a specific environment setup. However, it does not mention potential errors, rate limits, or side effects, though as a read-only operation with output schema, this is acceptable.
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 three sentences, front-loaded with verb and resource, then purpose and prerequisite. No unnecessary words; every sentence provides 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 zero parameters, existence of output schema, and sibling tools that cover other functions, the description is complete. It defines what it does, its role in the workflow, and a setup requirement.
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. Per guidelines, 0 params yields baseline 4. Description does not add parameter semantics, but none are needed.
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 verb 'Get' and resource 'structure of JACTUS documentation', listing files with section headers. It hints at usefulness before searching but does not explicitly distinguish from all sibling tools like jactus_get_topic_guide.
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?
Description advises using this tool to understand available documentation before searching, implying a pre-search use case. It also notes the requirement of JACTUS source tree access and setting the JACTUS_ROOT env var, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ACTUS event types with descriptions.
Returns event type codes (IED, IP, PR, MD, RR, etc.) and their meanings. Events represent cash flows and state transitions during a contract's life. Use this to understand the events returned by jactus_simulate_contract.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the read-only nature (lists event types), provides examples of codes, and explains that events represent cash flows and state transitions. No contradictions with annotations (none provided). Adequate for a simple information 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?
Three sentences, front-loaded with purpose, no wasted words. Each sentence adds value: purpose, output details, usage guidance.
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 zero parameters and presence of an output schema, the description is complete. It explains the return content and connects to a related tool (jactus_simulate_contract). 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?
The tool has zero parameters, and schema coverage is 100% trivially. No additional parameter semantics are needed.
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 'List all ACTUS event types with descriptions', using a specific verb and resource. It distinguishes from sibling tools that deal with contracts, risk, and simulation.
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 this to understand the events returned by jactus_simulate_contract.' No exclusions or alternatives needed given the narrow scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific code example's source code.
Returns the full source code, docstring, and metadata for an example. Use jactus_list_examples first to see available examples.
Note: Requires JACTUS source tree access. Set JACTUS_ROOT env var if needed.
Args: example_name: Name of the example (e.g., pam_example, interest_rate_swap_example).
| Name | Required | Description | Default |
|---|---|---|---|
| example_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it returns source code, docstring, and metadata. It also mentions the dependency on the JACTUS source tree, covering operational constraints.
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 concise (6 lines), front-loads the main action, and provides essential usage guidance without superfluous detail.
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 presence of an output schema, the description omits return value details appropriately. It covers purpose, usage, and prerequisites, but could mention error handling for invalid example names.
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 0%, so the description must add meaning. It provides an example value (e.g., pam_example) but lacks format constraints or a full list of acceptable names, offering only minimal extra context.
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 source code for a specific example, with a strong verb-resource pairing. It distinguishes itself from siblings like jactus_list_examples and jactus_run_example, which serve different purposes.
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 advises to use jactus_list_examples first and notes the JACTUS_ROOT environment variable requirement, providing clear when-to-use and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a simple quick start example showing a basic PAM contract simulation.
Returns ready-to-run Python code that creates a PAM (Principal at Maturity) contract and simulates it. Good starting point for learning the JACTUS API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns 'ready-to-run Python code' but does not elaborate on side effects or behaviors. With no annotations provided, the description adequately conveys that this is a read-only, non-destructive action.
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 concise with two sentences, no extraneous information. It front-loads the action and provides a brief explanation and use case.
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 zero parameters and the presence of an output schema, the description fully covers what the tool does, including the type of output (Python code) and its purpose (quick start for PAM simulation). No further context is needed.
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?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter details. It clearly explains the output, which is sufficient for a parameterless tool.
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 returns Python code for a basic PAM contract simulation, with a specific verb ('Get') and resource ('quick start example'). It distinguishes from sibling tools like jactus_get_example and jactus_list_examples by focusing on a simple introductory example.
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 states it is a 'good starting point for learning the JACTUS API,' which implies use by beginners. However, it lacks explicit guidance on when not to use it or alternatives (e.g., jactus_get_example for more complex examples).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a structured guide for a specific JACTUS topic.
Returns a comprehensive markdown guide on the requested topic. More focused than jactus_search_docs for common areas.
Args: topic: Topic name. Available: "contracts" (overview of all types), "behavioral" (behavioral observers, callout events, prepayment/deposit models), "scenario" (scenario management, bundling observers), "jax" (JAX integration and autodiff), "events" (event types and lifecycle), "attributes" (contract parameters and conventions), "array_mode" (batch simulation, portfolio API, GPU/TPU acceleration).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behaviors. It implies read-only retrieval by saying 'returns a guide', but does not explicitly state safety, auth needs, or side effects. Adequate but not thorough.
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?
Concise two-sentence opening plus formatted parameter list. No wasted words; front-loaded with purpose.
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?
With output schema present and good parameter description, the tool is well-covered. Could mention that topic must be one of the listed values or handle invalid input, but overall complete for a retrieval 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?
Schema description coverage is 0%, but description fully compensates by listing all valid topic names and explaining each, adding critical meaning beyond the schema's bare 'type: string'.
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 verb 'Get', resource 'structured guide', and explicitly distinguishes from sibling 'jactus_search_docs' by noting it's 'more focused for common areas'. Also lists available topics.
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 clear context on when to prefer this tool over jactus_search_docs, but does not address when not to use it or compare with other siblings like jactus_list_contracts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get JACTUS and MCP server version information.
Returns versions for both the MCP server and the JACTUS library, plus Python version and compatibility status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully carries the burden by stating it returns version info, implying a safe read operation. It could add more context (e.g., speed, availability), but it is sufficient for a simple version query.
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 immediately state the purpose and list the returned information. 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?
For a parameterless tool with an output schema, the description fully covers the purpose and return content. No gaps remain.
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 exist in the input schema, so the description does not need to add parameter meaning. Baseline 4 is appropriate given zero params.
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 version information for JACTUS and MCP server, plus Python version and compatibility. This is a specific verb+resource that distinguishes it from all sibling tools, which focus on contracts, risk, simulations, etc.
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?
It is obvious when to use this tool (to get version info). There are no alternatives or exclusion reasons needed since this is a unique purpose among siblings, but it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify MCP server and JACTUS are working correctly.
Checks that JACTUS is installed and importable, examples and docs are accessible, and contracts are registered. Returns status ("healthy", "degraded", or "unhealthy") with specific check results.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully explains behavior: it checks installation, docs accessibility, and contract registration, returning a status classification. It does not mention destructive actions or auth needs, which is acceptable for a read-only health check.
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 concise with a clear first sentence and a brief list of checks. It is front-loaded and avoids unnecessary detail, though it could use slightly more structured formatting.
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 has no input parameters and an output schema exists, the description adequately covers the return values and the scope of checks. It is complete for a simple health check 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?
There are no parameters, so schema coverage is 100%. The description adds meaning by explaining what the tool checks and the return structure, which is appropriate for a parameterless tool.
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 verifies that MCP server and JACTUS are working correctly, listing specific checks (installation, docs, contracts). This is a distinct purpose from sibling tools which focus on contracts, events, risk, etc.
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 implies usage for health verification, but does not explicitly state when to use vs alternatives or when not to use. However, the context makes it clear, and no sibling tool serves the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 18 available ACTUS contract types organized by category.
Returns contract types grouped into: principal (PAM, LAM, LAX, NAM, ANN, CLM), non-principal (UMP, CSH, STK), exotic (COM), and derivative (FXOUT, OPTNS, FUTUR, SWPPV, SWAPS, CAPFL, CEG, CEC).
Start here to discover which contract type matches your financial instrument. Follow up with jactus_get_contract_info for details or jactus_get_contract_schema for the required parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fully describes the output (grouped lists of contract types) and implies no side effects. There is no contradiction with annotations (none exist).
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 three sentences, each earning its place: purpose, categorized listing, and guidance. No wasted words or 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 (listing with no parameters) and that an output schema exists, the description is complete: it states what is returned, categorizes the types, and suggests next steps.
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 tool has no parameters, so baseline is 4. The description does not need to add parameter semantics, and it correctly avoids extraneous detail.
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 it lists all 18 ACTUS contract types organized by category, with a specific verb and resource. It distinguishes from siblings by suggesting follow-up tools for details or schemas.
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 advises to start here to discover contract types and suggests specific follow-up tools, providing clear context for initial exploration. It does not explicitly state when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available code examples in JACTUS.
Returns Python scripts and Jupyter notebooks from the examples directory. Use jactus_get_example to retrieve the code or jactus_run_example to execute it.
Note: Requires JACTUS source tree access. Set JACTUS_ROOT env var if needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Discloses it lists examples from a specific directory and notes the prerequisite. Implicitly read-only. Could add details on error behavior (e.g., if directory missing), but sufficient for basic usage.
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 plus a note — every sentence adds value. Front-loaded with main action. No wordiness.
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 0-parameter list tool with output schema present, description adequately covers purpose, returns, and prerequisites. No gaps given low complexity.
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 exist (input schema empty), so baseline is 4. Description does not need to add parameter details; it correctly states it lists all examples with no filters.
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 lists all available code examples in JACTUS, specifies return type (Python scripts and Jupyter notebooks), and distinguishes from sibling tools like jactus_get_example and jactus_run_example by mentioning them as retrieval/execution alternatives.
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 clear usage context (listing examples) and a prerequisite note (JACTUS source tree access and env var). Lacks explicit when-not-to-use or alternatives beyond get/run, but adequate for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available risk factor observer types with usage guidance.
Returns observer types organized by complexity, from simple constant values to advanced time-series and curve observers. Each entry includes a description, typical use case, and whether it's available via MCP or requires the Python API.
Use this to determine which risk factor approach to use with jactus_simulate_contract. For MCP simulation, you can use: constant_value (default), risk_factors (dict), or time_series (time-varying). For advanced observers (curves, composites, callbacks, JAX), use the Python API directly.
Also includes behavioral observers (PrepaymentSurfaceObserver, DepositTransactionObserver) that inject callout events into the simulation timeline. These require the Python API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the output structure (entries with description, use case, availability) and mentions behavioral observers. Lacks details on whether the tool has side effects, but it's a listing tool so read-only is 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 concise, well-structured, and front-loaded with the main purpose. 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 parameterless list tool with an output schema, the description provides complete context: what it does, how to use it, and what the output contains. It leaves no major 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?
No parameters exist, so baseline is 4. The description adds value by explaining what the output contains, which is beyond the empty 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 lists risk factor observer types with usage guidance. It specifies the output is organized by complexity, which distinguishes it from other listing tools like jactus_list_contracts.
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 to use this tool to determine which risk factor approach to use with jactus_simulate_contract. It also details which observers are available via MCP vs Python API, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a JACTUS example and return its output.
Runs the example in a subprocess with a 30-second timeout and returns stdout, stderr, and return code. Use jactus_list_examples to see available examples.
Note: Requires JACTUS source tree access. Set JACTUS_ROOT env var if needed.
Args: example_name: Name of the example (e.g., pam_example, lam_example).
| Name | Required | Description | Default |
|---|---|---|---|
| example_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description fully handles transparency. Discloses subprocess execution, 30-second timeout, output components, and dependency on JACTUS source tree and env var. Adequately transparent.
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?
Concise yet informative: three short paragraphs covering purpose, usage note, and parameter. No redundancy, well-organized with natural reading flow.
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?
Has output schema (context), so return values are covered. Description still mentions stdout/stderr/return code. With one parameter fully described and prerequisites noted, the description is complete for this tool's complexity.
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 0% coverage (no description), but the description compensates by explaining the single parameter 'example_name' with concrete examples (pam_example, lam_example), adding meaning beyond the schema's title.
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 'Execute a JACTUS example and return its output' with specific details on output (stdout, stderr, return code). Distinguishes from sibling jactus_get_example by mentioning jactus_list_examples to see available examples.
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 clear context: use to run an example, mentions timeout, environment variable requirement, and references jactus_list_examples for availability. Lacks explicit 'when not to use' but sufficiently guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search JACTUS documentation for specific topics.
Searches across architecture docs, contract guides, and the README. Returns matching lines with context. Use jactus_get_topic_guide for structured guides on common topics.
Note: Requires JACTUS source tree access. Set JACTUS_ROOT env var if needed.
Args: query: Search query (e.g., 'day count convention', 'state transition', 'rate reset', 'prepayment').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it returns matching lines with context, implying read-only behavior. Mentions requirement for source tree access, but could be more explicit about no side effects.
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 concise paragraphs with front-loaded purpose and differentiation. Every sentence adds value 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?
Output schema exists (though not shown), so return format explanation is not needed. Description covers purpose, usage, prerequisites, and parameter examples adequately for a search 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?
Schema has 0% coverage, but description compensates with concrete examples of valid queries (e.g., 'day count convention', 'state transition'). Adds meaning beyond the raw type definition.
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 searches JACTUS documentation for specific topics, with examples of query types. It distinguishes from sibling tool jactus_get_topic_guide, which provides structured guides.
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 jactus_get_topic_guide instead for structured guides. Also notes prerequisite of JACTUS source tree access and environment variable setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulate an ACTUS contract and return structured cash flow events.
Creates a contract from the provided attributes, runs the ACTUS simulation engine, and returns all generated events with payoffs, timing, and optional contract state snapshots. Supports ALL 18 contract types including composite contracts (SWAPS, CAPFL, CEG, CEC) via the child_contracts parameter.
Common workflow:
Use jactus_get_contract_schema to get required fields for your contract type
Build the attributes dict with those fields
Call this tool to simulate
Examine the events and summary in the response
Risk factor observer selection (in priority order):
time_series - Time-varying market data with interpolation (for rate resets)
risk_factors - Fixed per-identifier values (for static market data)
constant_value - Single constant for all risk factors (default: 0.0)
Output size management:
For contracts with many events, use event_limit and event_offset to paginate
If include_states=True produces output that is too large, events are auto-truncated to first 5 + last 5, with a pagination hint in the response
Args: attributes: Contract attributes dict. Must include contract_type (e.g., "PAM"), status_date (ISO date), contract_role ("RPA" or "RPL"), and type-specific required fields. Use jactus_get_contract_schema to see required fields. risk_factors: Dict mapping risk factor identifiers to constant values. Example: {"LIBOR-3M": 0.05, "USD/EUR": 1.18} time_series: Dict mapping identifiers to time-value pairs for time-varying data. Each entry is [date_string, value]. Example: {"LIBOR-3M": [["2024-01-01", 0.04], ["2024-07-01", 0.045]]} interpolation: Interpolation method for time_series: "step" (default) or "linear". Step uses the most recent known value; linear interpolates between points. Note: both modes give identical results when query dates exactly match data points. To see differences, use data points at different dates than resets. extrapolation: Extrapolation method for time_series: "flat" (default) or "raise". Flat returns the nearest endpoint value; raise returns an error. constant_value: Constant risk factor value (default 0.0). Used only when neither risk_factors nor time_series is provided. include_states: If True, include contract state before/after each event. Warning: this significantly increases output size for contracts with many events. event_limit: Maximum number of events to return. Use with event_offset for pagination. The summary always covers all events regardless. event_offset: Number of events to skip from the beginning (default 0). child_contracts: Dict mapping child identifiers to their attribute dicts. Required for composite contracts (SWAPS, CAPFL, CEG, CEC). Each child is simulated first, then its results are fed into the parent contract. The identifiers must match those referenced in the parent's contract_structure. Example for SWAPS: {"LEG1": {PAM attrs...}, "LEG2": {PAM attrs...}} Example for CAPFL/CEG/CEC: {"LOAN-001": {PAM attrs...}}
Returns: Dict with: success, contract_type, num_events, events (list of event dicts), summary (total_inflows, total_outflows, net_cashflow, first/last_event), initial_state, final_state, child_results (if child_contracts provided). If paginated: includes pagination dict. On error: success=False, error, error_type, hint.
| Name | Required | Description | Default |
|---|---|---|---|
| attributes | Yes | ||
| event_limit | No | ||
| time_series | No | ||
| event_offset | No | ||
| risk_factors | No | ||
| extrapolation | No | flat | |
| interpolation | No | step | |
| constant_value | No | ||
| include_states | No | ||
| child_contracts | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it explains auto-truncation of states, pagination, error response structure, and risk factor observer selection. It discloses all relevant side effects and constraints.
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 well-structured with headers and bullet points, front-loading the core purpose. It is somewhat lengthy but justified by the tool complexity; 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 the high complexity (10 parameters, nested objects, composite contracts), the description is complete: it covers workflow, risk factors, pagination, child contracts, and error handling. The presence of an output schema helps, but the description still adds essential 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?
The input schema has 0% description coverage, but the tool description adds extensive meaning for all 10 parameters, including examples, defaults, and usage notes. This fully compensates for the schema gap.
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 simulates an ACTUS contract and returns structured cash flow events. It differentiates from sibling tools like jactus_list_contracts and jactus_get_contract_info by specifying its unique function and workflow.
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 a common workflow and priority order for risk factor selection. While it gives clear context, it does not explicitly state when not to use this tool versus alternatives, missing some exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulate a portfolio of contracts and return aggregate results.
Simulates each contract and aggregates total inflows, outflows, and net cashflow across the portfolio. Returns per-contract summaries.
Args: contracts: Array of contract attribute dicts (same format as simulate). risk_factor_rate: Flat risk factor rate for all contracts (default 0.05).
| Name | Required | Description | Default |
|---|---|---|---|
| contracts | Yes | ||
| risk_factor_rate | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses main behavior: simulates each contract, aggregates totals, returns per-contract summaries. With no annotations, could explicitly state it is read-only/non-destructive, but simulation context makes it clear.
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 clear definition, then structured details. No unnecessary words. Well front-loaded.
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 inputs, aggregation method, and return type. With output schema present, doesn't need to list fields. Could mention that it returns aggregate results, which it does.
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 0%, but description explains both parameters: contracts is array of dicts (same format as simulate), and risk_factor_rate has default. Adds crucial meaning beyond schema titles.
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 it simulates a portfolio of contracts and returns aggregate results. Distinguishes from sibling jactus_simulate_contract by mentioning portfolio 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?
Implies usage for multiple contracts, references 'same format as simulate' linking to sibling tool. Missing explicit when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate contract attributes for correctness before simulation.
Checks that all required fields are present, values are valid, and types are correct. Returns field-level error messages and warnings for unknown fields. Call this before jactus_simulate_contract to catch errors early.
Args: attributes: Contract attributes dictionary to validate. Should include contract_type, status_date, contract_role, and type-specific fields.
| Name | Required | Description | Default |
|---|---|---|---|
| attributes | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool checks required fields, valid values, correct types, and returns field-level error messages and warnings for unknown fields. It also implies no side effects (read-only validation). Could mention auth or rate limits, but acceptable.
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 concise with 5 sentences, each serving a purpose. First sentence gives main purpose, then explains checks, return values, usage, and parameter documentation. No wasted words, front-loaded.
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, validation purpose), the description covers what it does, when to use it, what it returns, and parameter expectations. Output schema likely covers return structure, so no need for more detail. Complete for 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?
The input schema for 'attributes' is generic (object with additionalProperties). The description adds meaning by specifying expected fields like contract_type, status_date, contract_role, and type-specific fields. Schema coverage is 0%, so description compensates well, though not exhaustive.
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 validates contract attributes for correctness before simulation. It uses specific verb 'validate' and resource 'contract attributes'. It distinguishes from siblings by mentioning it should be called before jactus_simulate_contract.
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 advises calling this tool before jactus_simulate_contract to catch errors early. This provides a clear usage context, though it does not mention alternatives or when not to use it.
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.2.0jactus_compute_riskjactus_get_contract_infojactus_get_contract_schemajactus_get_doc_structurejactus_get_event_typesjactus_get_examplejactus_get_quick_startjactus_get_topic_guidejactus_get_version_infojactus_health_checkjactus_list_contractsjactus_list_examplesjactus_list_risk_factor_observersjactus_run_examplejactus_search_docsjactus_simulate_contractjactus_simulate_portfoliojactus_validate_attributesEach tool has a clearly distinct purpose: listing contracts, getting info/schema, simulating single or portfolio, computing risk, validating, searching docs, etc. No overlap causes ambiguity.
All tools follow the pattern `jactus_verb_noun` in snake_case, e.g., `jactus_list_contracts`, `jactus_simulate_contract`. No mixing of styles.
18 tools is appropriate for a financial contract simulation server, covering the full workflow (exploration, simulation, risk, validation, documentation) without being excessive.
The tool surface covers the entire lifecycle: discovery (list, info, schema), simulation (single, portfolio, risk), validation, documentation search, and health checks. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic liquidity and leverage ratio tools for AI agents — current, quick and cash ratios, defensive interval, debt-to-equity, debt-to-assets, equity multiplier and interest coverage via Model Context Protocol. Useful for corporate finance, credit analysis, financial analysis, financial formulas and financial modeling.
Connect AI agents to financial institution origination, analytics, and compliance workflows.
Deterministic time-value-of-money and fund-performance tools for AI agents — future value, present value, CAGR, annuities, perpetuities, loan payments, payback, discounted payback, DPI, RVPI and TVPI via Model Context Protocol. Useful for corporate finance, financial projections, financial analysis, quantitative analysis, financial formulas and financial modeling.
Industry-standard bond math for AI agents: price, yield, accrued interest, duration, yield-to-worst
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pedronahum/JACTUS-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
