Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
Jarvis is a FastAPI-based personal assistant with 20 tools spanning calendar, expenses, email, and weather. Tool definitions are present with descriptions and basic input schemas, but lack depth in several critical areas. Naming is generally clear (verb-noun convention), but descriptions are inconsistent in quality and length. Parameter schemas lack granularity, many are missing enum constraints, range validation, and explicit format specifications. No output schemas are documented, making it unclear what fields agents should expect to receive. Error handling is not evident in the tool definitions. This is a D+/C- server: functional but with significant gaps that would require refinement before production use.
Tools (20)
add_expensewriteauth50/100
Add a new expense with amount, description, category, and date
add_expense_to_folderwriteauth50/100
Assign one or more expenses to a folder
create_eventwriteauthsource verified78/100
Create a new calendar event with name, start time, and optional end time, description, location, and color
create_folderwriteauthsource verified72/100
Create a new folder to group related expenses with optional image
Missing enum constraints on multi-choice parameters. 'color' in create_event lists valid values in description but lacks formal enum schema; 'category' in add_expense similarly lacks enum. LLMs may hallucinate invalid values.
Convert multi-choice parameters to formal enum constraints in schema. E.g., color: {"type": "string", "enum": ["lavender", "sage", "grape", "flamingo", "banana", "tangerine", "peacock", "graphite", "blueberry", "basil", "tomato"]}. Remove the enumeration from the description once schema is formal.
Expand descriptions for destructive tools (delete_event, delete_expense) to include confirmation/dry-run patterns. Example: 'Delete a calendar event by ID. WARNING: This action is irreversible. Consider calling list_events first to confirm the event ID, or provide a dry_run=true parameter for preview before deletion.'
Add pagination metadata to list tools. Expand list_events description: 'List calendar events with optional filtering. Returns up to limit results. If more events exist beyond limit, the response includes a next_cursor field for pagination. Use next_cursor in a follow-up call to fetch additional results.'
Score history
Overall score trend
↑ 9 points across a rubric change (v1 → v2)
62/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
C
62
2026-07-28+
v2
2026-03-09
D
53
-
v1
get_emailread onlyauthsource verified72/100
Get a specific email by ID with full content
get_eventread onlyauthsource verified70/100
Get a specific calendar event by ID
get_expense_summaryread onlyauth50/100
Get a summary of expenses including totals by category and time period
get_weatherread onlyauth50/100
Get current weather information for a location by latitude and longitude
list_emailsread onlyauthsource verified74/100
List emails from the inbox with optional search query and caching
list_eventsread onlyauthsource verified74/100
List calendar events within a date range with optional text search filtering
list_foldersread onlyauthsource verified72/100
List all expense folders with expense counts and totals
query_expensesread onlyauth50/100
Query expenses with optional filtering by category, date range, and folder
query_folder_expensesread onlyauth50/100
Query expenses within a specific folder
reply_to_emailwriteauthsource verified75/100
Reply to an existing email with quoted subject and threading headers
send_emailwriteauthsource verified77/100
Send a new email with recipient, subject, and body
Destructive operations (delete_event, delete_expense, reply_to_email) lack confirmation/dry-run patterns. Agents can irreversibly delete data without safeguards.
Short descriptions on read-only discovery tools. 'Get a specific calendar event by ID' (41 chars) and 'Get a specific email by ID with full content' (44 chars) lack context about when to use vs similar tools.
No pagination guidance. 'list_emails' accepts max_results up to 100 (default 20), but no documentation on how to handle result truncation, next cursors, or total counts.
Parameter range constraints missing. 'limit' in list_events is stated as '1-100, default 20' in description, but no min/max in schema. 'lat'/'lon' in get_weather lack explicit range validation in schema.
No error recovery guidance in tool descriptions. If a create_event or send_email fails, the LLM has no actionable next steps (retry, user input, fallback).
Ambiguous parameter dependencies not documented. 'add_expense_to_folder' takes an array of expenseIds, LLM may not know how to construct this without seeing examples or output format of list_expenses.
Timezone parameter in create_event and update_event defaults to Europe/Rome but is documented inline only. LLM may not recognize timezone conflicts or tz-aware formatting requirements.
create_eventupdate_event
Document parameter relationships in descriptions. E.g., add_expense_to_folder: 'Assign one or more expenses (obtained via query_expenses) to a folder. expenseIds must be a JSON array of strings, e.g., ["exp_123", "exp_456"].'
Add recovery guidance to mutation tools. E.g., send_email: 'Send a new email with recipient, subject, and body. On failure, check that recipient is a valid email address and body is under 50,000 characters. Retries are safe (tool is idempotent by message ID).'
Rename ambiguous parameters. 'q' in list_events → 'search_query' or 'text_search'. 'folderId' in add_expense → 'expense_folder_id' to reduce confusion with email folders.
Add a discovery tool (list_expense_categories) to help agents understand valid categories without hardcoding them in descriptions. Similarly, offer list_event_colors to expose valid color enums.
Document which tools return IDs suitable for chaining. E.g., create_event returns event_id (usable in update_event, delete_event, get_event); add_expense returns expense_id (usable in update_expense, delete_expense). This prevents wasteful lookup calls.