Skip to main content
Glama
rezazadeh93

Hermes DB

by rezazadeh93

add_program

Insert a university program into Hermes DB, returning the existing ID when the program URL already exists to prevent duplicates.

Instructions

Insert a program. If program_url already exists, return that id without inserting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNo
intakeNo
countryNo
universityYes
backend_fitNo
degree_typeNo
overall_fitNo
program_urlYes
source_urlsNo
degree_levelNo
program_nameYes
subject_areaNo
uncertaintiesNo
research_statusNodiscovered
application_startNo
curriculum_summaryNo
eligibility_statusNounknown
english_requirementNo
academic_eligibilityNo
application_deadlineNo
work_experience_requirementNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses idempotency semantics (existing program_url short-circuits the insert and returns the existing id). It says nothing about required fields, defaults (research_status='discovered', eligibility_status='unknown'), permissions, or what happens with partial/duplicate data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste, with the idempotency rule front-loaded immediately after the action statement. Nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, but a 21-parameter write tool with no annotations and no schema descriptions needs far more than two sentences. Required-field guidance, defaults, and failure/duplicate handling are all absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

21 parameters at 0% schema description coverage, and the description explains meaning for only one of them (program_url as the uniqueness key). The remaining 20 fields, including the required university and program_name, get no added semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Insert a program', and it names the dedup key (program_url). It does not explicitly differentiate itself from siblings like update_program_fit or get_program, but the operation is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance or mention of alternatives. The dedup conditional ('if program_url already exists, return that id') is a behavioral rule, not routing advice, so the agent gets no help deciding between this and update_program_fit or get_program.

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